enhance: Add comprehensive .gitignore for deb-mock project
Some checks failed
Build Deb-Mock Package / build (push) Successful in 54s
Lint Code / Lint All Code (push) Failing after 1s
Test Deb-Mock Build / test (push) Failing after 36s

- Add mock-specific build artifacts (chroot/, mock-*, mockroot/)
- Include package build files (*.deb, *.changes, *.buildinfo)
- Add development tools (.coverage, .pytest_cache, .tox)
- Include system files (.DS_Store, Thumbs.db, ._*)
- Add temporary and backup files (*.tmp, *.bak, *.backup)
- Include local configuration overrides (config.local.yaml, .env.local)
- Add test artifacts and documentation builds
- Comprehensive coverage for Python build system project

This ensures build artifacts, chroot environments, and development
tools are properly ignored in version control.
This commit is contained in:
robojerk 2025-08-18 23:37:49 -07:00
parent 1a559245ea
commit 4c0dcb2522
329 changed files with 27394 additions and 965 deletions

View file

@ -1,209 +1,109 @@
# Deb-Mock Configuration
---
layout: default
title: Mock configuration
---
Deb-Mock uses YAML configuration files to define build environments and behavior. This document describes all available configuration options.
## Mock configuration files
## Configuration File Format
Syntactically, Mock configuration files are just Python files. But you should
be rather conservative and use just the `config_opts[]` dictionary because we'd
like to [change the format in the future](https://github.com/rpm-software-management/mock/issues/1060).
Deb-Mock configuration files use YAML format. Here's a complete example:
Mock RPM package self-documents all the available options, take a look at this
file:
```yaml
# Basic configuration
chroot_name: bookworm-amd64
architecture: amd64
suite: bookworm
output_dir: ./output
keep_chroot: false
verbose: false
debug: false
$ rpm -qd mock | grep site-defaults
/usr/share/doc/mock/site-defaults.cfg
# Chroot configuration
chroot_dir: /var/lib/deb-mock/chroots
chroot_config_dir: /etc/schroot/chroot.d
Mock configuration files can be logically divided into *generic* (used for every
executed Mock command) and *chroot* configuration (used only if the
corresponding chroot is selected, see below).
# sbuild configuration
sbuild_config: /etc/sbuild/sbuild.conf
sbuild_log_dir: /var/log/sbuild
Both the *generic* and *chroot* configuration can be done on either
*system* level (`/etc/mock` directory) or on *user* level (files in
`$HOME/.config` directory).
# Build configuration
build_deps: []
build_env:
DEB_BUILD_OPTIONS: parallel=4
DEB_BUILD_PROFILES: nocheck
build_options:
- --verbose
- --debug
# Metadata configuration
metadata_dir: ./metadata
capture_logs: true
capture_changes: true
```
### Selecting a chroot config
## Configuration Options
For example to initialize a Fedora Rawhide x86_64 chroot (using
`/etc/mock/fedora-rawhide-x86_64.cfg` file), and switch into the chroot, one can
do:
### Basic Configuration
$ mock -r fedora-rawhide-x86_64 --shell
| Option | Type | Default | Description |
|--------|------|---------|-------------|
| `chroot_name` | string | `bookworm-amd64` | Name of the chroot environment to use |
| `architecture` | string | `amd64` | Target architecture for builds |
| `suite` | string | `bookworm` | Debian suite (bookworm, sid, bullseye, buster) |
| `output_dir` | string | `./output` | Directory for build artifacts |
| `keep_chroot` | boolean | `false` | Whether to keep chroot after build |
| `verbose` | boolean | `false` | Enable verbose output |
| `debug` | boolean | `false` | Enable debug output |
Note we are not using the `.cfg` suffix in the `-r` option in this case. This
way the *user* level `$HOME/.config` files are searched for the corresponding
`.cfg` file first, and since nothing is found, then the *system* level file is
found in `/etc/mock` (and used).
### Chroot Configuration
One can though use a config pathname with the `-r` option, too. But the
pathname must represent an existing file (accessible from the current working
directory):
| Option | Type | Default | Description |
|--------|------|---------|-------------|
| `chroot_dir` | string | `/var/lib/deb-mock/chroots` | Directory for chroot environments |
| `chroot_config_dir` | string | `/etc/schroot/chroot.d` | Directory for schroot configuration files |
$ mock -r ./subdir/existing-config-file.cfg --shell
$ mock -r /etc/mock/fedora-35-x86_64.cfg
### sbuild Configuration
### Generic configuration changes
| Option | Type | Default | Description |
|--------|------|---------|-------------|
| `sbuild_config` | string | `/etc/sbuild/sbuild.conf` | Path to sbuild configuration file |
| `sbuild_log_dir` | string | `/var/log/sbuild` | Directory for sbuild logs |
Typically the file `$HOME/.config/mock.cfg` should be used for *generic*
configuration changes for a single user. If a *system* Mock behavior change
is desired (for all system users), then use `/etc/mock/site-defaults.cfg`.
### Build Configuration
The `site-defaults.cfg` is typically empty by default, but contains a basic
documentation and a valid link to a **complete configuration documentation**.
That documentation typically is `/usr/share/doc/mock/site-defaults.cfg`
(location may vary depending on your host system conventions).
| Option | Type | Default | Description |
|--------|------|---------|-------------|
| `build_deps` | list | `[]` | Additional build dependencies to install |
| `build_env` | dict | `{}` | Environment variables for builds |
| `build_options` | list | `[]` | Additional sbuild options |
### Metadata Configuration
### Chroot configuration changes
| Option | Type | Default | Description |
|--------|------|---------|-------------|
| `metadata_dir` | string | `./metadata` | Directory for build metadata |
| `capture_logs` | boolean | `true` | Whether to capture build logs |
| `capture_changes` | boolean | `true` | Whether to capture .changes files |
There are `/etc/mock/<buildroot>.cfg` files for various build chroots that
contain various compatibility settings related to the target distribution
(location of RPM repositories, if DNF or YUM should be used, working directory
to be used, and so on).
## Supported Architectures
These system files are shipped via the `mock-core-configs` (or other), and users
are discouraged from changing these (change would break the automatic update of
such file with an updated version of the package). It is safer to install an
*override* configuration file:
- `amd64` - 64-bit x86
- `i386` - 32-bit x86
- `arm64` - 64-bit ARM
- `armhf` - 32-bit ARM (hard float)
- `ppc64el` - 64-bit PowerPC (little endian)
- `s390x` - 64-bit IBM S390
$ cat $HOME/.config/mock/fedora-35-x86_64.cfg
# include the default configuration
include("/etc/mock/fedora-35-x86_64.cfg")
# install make into the minimal build chroot
config_opts['chroot_additional_packages'] = 'make'
## Supported Suites
You may also copy and edit an existing configuration file into a new one:
- `bookworm` - Debian 12 (stable)
- `sid` - Debian unstable
- `bullseye` - Debian 11 (oldstable)
- `buster` - Debian 10 (oldoldstable)
$ cp /etc/mock/fedora-rawhide-x86_64.cfg ~/.config/mock/foo.cfg
## Environment Variables
The default chroot configuration file is `/etc/mock/default.cfg`, which is
usually a symlink to one of the installed chroot configuration files. You may
create another symlink to an installed configuration file to change the default
chroot config file:
Common environment variables you can set in `build_env`:
$ ln -s /etc/mock/fedora-rawhide-x86_64.cfg ~/.config/mock/default.cfg
```yaml
build_env:
DEB_BUILD_OPTIONS: parallel=4,nocheck
DEB_BUILD_PROFILES: nocheck
DEB_CFLAGS_SET: -O2
DEB_CXXFLAGS_SET: -O2
DEB_LDFLAGS_SET: -Wl,-z,defs
```
If Koji is already using a config you need, then you can use the Koji client
tool for generating the file:
## Build Options
$ koji mock-config --tag f21-build --arch=aarch64 f21 > ~/.config/mock/foo.cfg
Common sbuild options you can add to `build_options`:
Similar functionality has the Copr client tool:
```yaml
build_options:
- --verbose
- --debug
- --no-clean-source
- --no-run-lintian
- --no-run-autopkgtest
```
$ copr mock-config @copr/copr-dev fedora-21-x86_64 > ~/.config/mock/foo.cfg
## Configuration File Locations
When your file `foo.cfg` is installed, you can just do `mock -r foo [...]`.
Deb-Mock looks for configuration files in the following order:
### Order of loading the files
1. Command line specified file (`--config` option)
2. `./deb-mock.conf`
3. `~/.config/deb-mock/config.yaml`
4. `/etc/deb-mock/config.yaml`
5. Default configuration
The order of reading and evaluating configuration files in Mock is the following:
## Example Configurations
1. `/etc/mock/site-defaults.cfg`
1. `/etc/mock/<buildroot>.cfg` or `~/.config/mock/<buildroot>.cfg`
1. `~/.mock/user.cfg`
1. `~/.config/mock.cfg` (since `mock-1.2.15`)
### Minimal Configuration
```yaml
chroot_name: bookworm-amd64
architecture: amd64
suite: bookworm
```
### Development Configuration
```yaml
chroot_name: sid-amd64
architecture: amd64
suite: sid
output_dir: ./build-output
keep_chroot: true
verbose: true
debug: true
build_env:
DEB_BUILD_OPTIONS: parallel=8,nocheck
DEB_BUILD_PROFILES: nocheck
build_options:
- --verbose
- --no-run-lintian
```
### Production Configuration
```yaml
chroot_name: bookworm-amd64
architecture: amd64
suite: bookworm
output_dir: /var/lib/deb-mock/output
keep_chroot: false
verbose: false
debug: false
build_env:
DEB_BUILD_OPTIONS: parallel=4
build_options:
- --run-lintian
- --run-autopkgtest
metadata_dir: /var/lib/deb-mock/metadata
```
## Validation
Deb-Mock validates configuration files and will report errors for:
- Invalid architectures
- Invalid suites
- Missing required directories
- Invalid file paths
## Command Line Overrides
Most configuration options can be overridden on the command line:
```bash
# Override chroot
deb-mock build --chroot=sid-amd64 package.dsc
# Override architecture
deb-mock build --arch=arm64 package.dsc
# Override output directory
deb-mock build --output-dir=/tmp/build package.dsc
# Keep chroot for debugging
deb-mock build --keep-chroot package.dsc
```
I.e. the value set in the later configuration file overrides the value set by
previously loaded files.