Skip to main content

job: koji_build

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 default dist-git branch (usually rawhide). Packit configs on other branches are ignored.

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 workflow is preserved, details here. You can override this behaviour by specifying allowed_pr_authors and/or 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 allowed_pr_authors.

danger

Due to a bug, if you merge a PR containing more than one commit or push more than one commit directly, the job may not be triggered even though all conditions are met. In such case please trigger it manually.

Packit provides an overview of its own builds here.

The koji build behaves as it was created manually, and you can utilise Fedora Notifications 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 Koji builds from upstream, see upstream_koji_build.

Downstream configuration template

You can use our downstream configuration template for creating your Packit configuration in dist-git repository.

Automate the setup

You can also use packit dist-git init CLI command to create your Packit dist-git configuration.

Supported triggers​

  • commit - reacts to new commits to the specified branch (in dist-git)
  • koji_build - reacts to tagging of a Koji build into the configured sidetag group More info about releasing multiple packages together using sidetags can be found here.
You can use both triggers simultaneously
- job: koji_build
  trigger: commit | koji_build

Required parameters​

  • dist_git_branches - the name of the dist-git branch we want to build for. You can also use the aliases provided by Packit to not need to change the config file when the new system version is released.

Optional parameters​

  • scratch - defaults to false, use to create scratch (test) builds instead of the real production builds
  • allowed_pr_authors - a list of PR authors whose merged pull requests will trigger Koji builds (defaults to ['packit']). As each item of the list you can specify:
    • name of a FAS account, e.g. my-fas
    • name of a group - starting with @, e.g. @my-sig (don't forget to put the group name in quotes - a token in YAML is not allowed to start with @)
    • all_admins alias - allowing all users with admin access to the dist-git repo
    • all_committers alias - allowing all users with commit access to the dist-git repo
  • allowed_committers - a list of committers whose direct pushes to dist-git will trigger Koji builds (defaults to an empty list). It is enough to configure the allowed_pr_authors option if you want to have Koji builds triggered only by merged pull requests. Similarly to the previous option, as each item of the list you can specify:
    • name of a FAS account, e.g. my-fas
    • name of a group - starting with @, e.g. @my-sig (don't forget to put the group name in quotes - a token in YAML is not allowed to start with @)
    • all_admins alias - allowing all users with admin access to the dist-git repo
    • all_committers alias - allowing all users with commit access to the dist-git repo
  • sidetag_group - name of a sidetag group this Koji build should be tagged into. The name has to be unique across all projects that use Packit, so don't hesitate to be descriptive. A good convention is to use ${package1}-${package2}...${packageN}-updates. If specified, after a build finishes it is tagged into a sidetag (that is created if it doesn't already exist) corresponding to the dist-git branch of the build.
  • dependencies - list of downstream package names that are required to be tagged into the configured sidetag group for this job to be triggered. For example, if you want to ensure that a koji_build job with the same sidetag group configured in package foo is run first, you need to list foo here.
  • dependents - list of downstream package names that should react to tagging of this build into the configured sidetag group. For example, if a koji_build job with the same sidetag group configured in package bar is supposed to be triggered after this build finishes, you need to list bar here.
  • require.label - you can specify labels that have to be present/absent on a pull request in order to trigger the build when it is merged. See configuration details here.

Retriggering​

For retriggering the job, see retriggering docs.

Processing of dist-git events from Pagure​

Processing of dist-git events from Pagure

Because of the potential issues with rendering:

  • dotted lines represent no
  • continous lines represent yes

Example​

issue_repository: https://github.com/my-username/packit-notifications

jobs:
- job: koji_build
  trigger: commit
  allowed_committers: ["jsmith"]
  dist_git_branches:
    - fedora-all
    - epel-8