Trigger the build in Fedora Koji build system as a reaction to a new dist-git commit. A Packit config file needs to be in the dist-git repository to allow this job to be triggered. Packit loads the config from the newly pushed commit (therefore, the Packit configuration needs to be in each branch Packit should act upon).
The build is triggered only for commits with a spec-file change.
By default, only merged pull requests created by Packit are being acted upon so the proven packager
here. You can override this behaviour by specifying
allowed_committers in the job configuration (see below). For direct pushes, the committer needs to
be specified in the
allowed_committers and for merged pull requests the author of the PR needs to be
specified in the
There is no UI provided by Packit for the job,
but it is visible across Fedora systems (as you can see in the following image).
The koji build behaves as it was created manually, and you can utilise
to be informed about the builds. Also, you can configure a repository where should we
open issues in case of errors during the job via
issue_repository configuration key.
For retriggering the job, see our release guide.
For Koji builds from upstream, see
- commit - reacts to new commits to the specified branch (in dist-git)
- dist_git_branches - the name of the dist-git branch we want to build for when using commit trigger. You can also use the aliases provided by Packit to not need to change the config file when the new system version is released.
- scratch - defaults to
false, use to create scratch (test) builds instead of the real production builds
- allowed_pr_authors - a list of FAS accounts of PR authors whose merged pull requests will trigger koji builds
- allowed_committers - a list of FAS accounts of committers whose direct pushes to dist-git will trigger koji builds (defaults to an empty list). You do not need to configure this option if you want to have koji builds triggered only by merged pull requests.
- job: koji_build