Packit Service jobs configuration
Packit Service doesn't have any web interface, but its behaviour can be configured via the config file generally described here.
The tasks Packit Service should do should be defined in the jobs
section. The section is a list of dictionaries:
jobs:
- {key: value}
- {}
When there is an action (pull request, commit, etc.) in the upstream repository, Packit Service takes the config
file from the relevant git ref (release tag for release, PR head for pull requests, related dist-git commit for downstream jobs).
Then, it tries to find a matching job in the jobs
sections for the particular event (e.g. for pull request, jobs with
pull_request
trigger are matched).
If there is no jobs
section in the configuration file, jobs default to:
jobs:
- job: copr_build
trigger: pull_request
targets: [fedora-stable]
- job: tests
trigger: pull_request
targets: [fedora-stable]
- job: propose_downstream
trigger: release
dist_git_branches:
- fedora-all
If you do not want to use the jobs then the jobs
section in the configuration file should be empty:
jobs: []
Packit configuration supports YAML Merge Key syntax, which can be used to reduce duplication of configuration. Please see the example:
# before
jobs:
- job: copr_build
trigger: pull_request
targets:
- centos-stream-8-x86_64
- centos-stream-9-x86_64
- fedora-all
- job: copr_build
trigger: commit
branch: main
targets:
- centos-stream-8-x86_64
- centos-stream-9-x86_64
- fedora-all
# after
jobs:
- &copr
job: copr_build
trigger: pull_request
targets:
- centos-stream-8-x86_64
- centos-stream-9-x86_64
- fedora-all
- <<: *copr
trigger: commit
branch: main
Configuration keys
job
(str) name of the job (you can imagine this as a CLI command).
trigger
(str) what is the trigger for the job? Every job only supports a specific set of triggers.
packages
(list) Optional, list of package object names (when using monorepositories). If a job object has no such key,
all packages of a monorepo should be handled. The package object names need to be defined
in the packages
dictionary.
Here is an example of the configuration of the job including the packages
:
jobs:
- job: copr_build
trigger: pull_request
targets:
- fedora-all
- epel-8
packages:
- copr-frontend
- copr-backend
manual_trigger
(bool) Option that enables triggering the job only manually (via pull-request/issue comment or rerunning GitHub check).
Defaults to false
.
Overriding global parameters in jobs
You are able to override your global parameters (such as specfile_path
,
downstream_package_name
,
actions
...) for every job. This is very useful
when you want to set up a build or a test matrix using different parameters or
configuration. It's also useful when your release workflow differs between
Fedora and EPEL.
In order to do such a thing, just set a value you want to override in the respective job.
Example:
specfile_path: package.spec
jobs:
- job: some-job
trigger: ran-out-of-beer
targets: [fedora-stable]
specfile_path: somewhere/else/package.spec
In this example, the job some-job
would override specfile_path
to
somewhere/else/package.spec
instead of using ./package.spec
.
Supported jobs
- Upstream jobs
- Downstream jobs