Configuration #
Packit uses a configuration file in the upstream repository. The config file is written in YAML language.
You should place the file in the root of your upstream repo. Packit accepts these names:
.packit.yaml
.packit.yml
packit.yaml
packit.yml
Both Packit Service and packit tool use this configuration file.
Top level keys #
specfile_path #
(string) Relative path to a spec file within the upstream repository. If not specified, defaults to:
downstream_package_name.spec
ifdownstream_package_name
is set.- (deprecated) Else recursively search the tree and use the first spec file found.
If there are only test jobs with skip_build
option defined (more about it here),
spec file doesn’t need to be present and its path doesn’t need to be defined in the config.
The functionality to recursively search for a specfile is deprecated and it’s
going to be removed in a
future version (>0.64.0) of Packit. We recommend projects to explicitly set
specfile_path
or rely on the <downstream_package_name>.spec
default, by
setting downstream_package_name
.
upstream_project_name (deprecated)
#
(string) Deprecated since packit-0.7.0, use upstream_package_name
instead.
upstream_package_name #
(string) Name of the upstream repository (e.g. in PyPI), defaults to the name of the GitHub repository; it’s used when working with the upstream project, as a release archive name and as a directory name in that archive.
upstream_project_url #
(string) URL of the upstream git project (e.g.
https://github.com/packit/packit
).
create_pr (only in CLI) #
(bool) When doing a new update in Fedora dist-git, should packit create a
new pull request (defaults to true
) or push directly to dist-git (if set to
false
). This option can be used only locally in the CLI, but can be overriden
via --pr/--no-pr
option. Deployed Packit (on GitHub or GitLab) ignores this
setting, because Packit Team does not endorse automated release from created
release to the Bodhi update without any quality assurance.
merge_pr_in_ci #
(bool) When Packit clones your repository while creating RPMs from your pull
requests, it by default merges the pull request checkout into the main
repository branch to be sure the changes are up to date. You can disable this
behaviour by setting this field to false
which will make Packit to work with
your pull request git ref as it is.
sync_changelog #
(bool) When doing a new update in Fedora dist-git, the specfile changelog
is synchronized when set to true
. By default (false
), everything but the changelog
part is synchronized. Use this only when your changelogs are in sync since this overwrites the changelog in the downstream.
synced_files (deprecated)
#
(list of strings or dicts) A list of relative paths to files in the upstream repo which are meant to be copied to dist-git during an update (spec file path and config file path are set every time by default).
It is now deprecated in favor of files_to_sync
.
update_release #
(bool) Packit by default modifies Release in the spec file when creating a SRPM. If you don’t want this, you can prevent it with
update_release: false
release_suffix #
(templated string) String that can be used to override the default release suffix generated by Packit. The suffix will be expanded, and you can use following variables:
PACKIT_PROJECT_VERSION
- version fromgit describe
PACKIT_RPMSPEC_RELEASE
- release from specfilePACKIT_PROJECT_COMMIT
- commit SHA from which the SRPM is builtPACKIT_PROJECT_BRANCH
- branch from which the SRPM is built
Example usage:
release_suffix: "dev.{PACKIT_PROJECT_BRANCH}"
When unset, default release suffix that is generated by Packit is following:
{original_release_number}.{current_time}.{sanitized_current_branch}{git_desc_suffix}
It is also possible to define release_suffix
at the top-level of your packit
config. In that situation all jobs and SRPM, Copr, Koji and RPM build from CLI
will inherit the release_suffix
that you have set. We advise caution when
doing such thing, because inheriting the release suffix value by Copr or Koji
build may easily cause confusion, break the ordering of the NVRs of the RPMs and
also may cause usage of RPMs that are not meant for production use. In such
scenarios, please try to make sure RPMs built by Packit are easily
distinguishable from the RPMs meant for production use. To prevent the
inheritance, you can define:
release_suffix: null
If you don’t want the release to be modified at all, see update_release.
files_to_sync #
(list of strings or dicts) A list of relative paths to files in the upstream repo which are meant to be copied to dist-git during an update.
Spec file path and config file path are always included by packit init
but can be manually removed from the list.
Under the hood this will use rsync --archive
to synchronise the paths
between the upstream and the dist-git repo.
The fields for a dictionary item in the list are the following:
- src: A single path or a list of paths in the upstream repo that should be synced to dist-git.
- dest: Path in the dist-git repo, where paths in
src
should be synced to. - mkpath: Flag to indicate if missing path components in
dest
should be created or not (default: false). - delete: Flag to indicate if extra content from
dest
should be deleted (default: false). - filters: List of rsync filter rules to be used during syncing.
Examples: #
Copy a file from root of the upstream repo to dist-git:
files_to_sync:
- packit.spec
If you copy packit.yaml
downstream, you can then take advantage of
sync-from-downstream
command:
files_to_sync:
- .packit.yaml
Rename or change the path of the synced file in dist-git:
files_to_sync:
- src: packit.spec
dest: redhat/packit.spec
Paths also support globs. Copy everything from fedora-packaging
folder and
put it to the root of the dist-git repo:
files_to_sync:
- src: fedora-packaging/*
dest: .
Sync the entire content of the fedora-packaging
directory, and delete extra
content found in the root of the dist-git repo; protect .git*
files and the
sources
file from deletion:
files_to_sync:
- src: fedora-packaging/
dest: .
delete: true
filters:
- "protect .git*"
- "protect sources"
Specify multiple source files to copy:
files_to_sync:
- src:
- package.spec
- some-file
dest: .
Set mkpath
to true
to create missing path components in dist-git.
In the example below, subdir
is created if missing.
files_to_sync:
- src: some.file
dest: subdir/some.file
mkpath: true
create_sync_note #
(bool) Create or update a README.packit file in dist-git when doing a new update,
telling that the repository is maintained by Packit and marking the version of packit
creating the update.
By default, this option is set to true
. When set to false
, README.packit is not created or updated.
(A previously created README.packit needs to be removed manually).
upstream_ref #
(string) Git reference to last upstream git commit (for source-git repos).
Can be set to commit hash, tag or a branch name. You can also use globbing pattern
to find a tag. In case you want to use globbing pattern for a branch, prefix the
pattern with branches/
, e.g. for a branch matching *-release
set to branches/*-release
.
downstream_package_name #
(string) Name of the RPM package in Fedora, defaults to the name of the GitHub repository.
dist_git_namespace #
(string) Namespace in dist-git URL (defaults to rpms
).
dist_git_base_url #
(string) URL of dist-git server, defaults to https://src.fedoraproject.org/ (has to end with a slash).
create_tarball_command (deprecated)
#
Please use create-archive
action
current_version_command (deprecated)
#
Please use get-current-version
action
actions #
(string) Custom actions/hooks overwriting the default behavior of packit (more in Actions).
jobs #
(list of dicts) A list of job definitions for packit service: see below for details.
allowed_gpg_keys #
(list of string) A list of gpg-key fingerprints; if specified, one of the
configured keys have to sign the last commit when updating in downstream; add
GitHub key (5DE3E0509C47EA3CF04A42D34AEE18F83AFDEB23
) if you want to use
this on code merged via GitHub web interface.
spec_source_id #
(int or string) Numeric ID of Source inside spec file which packit should
change when setting path to the newly generated tarball, can be also full name
of the macro. Defaults to Source0
or Source
, whichever is found first in
the spec file.
upstream_tag_template #
(string) Packit by default expects git tags to match versions (e.g. when
doing the propose-downstream
command) -
if you are using a different tagging scheme, let’s say v1.2.3
you can then set this parameter to v{version}
and
packit will fill in the version argument.
archive_root_dir_template #
(string) In the fix-spec-file
action Packit changes first %setup
(or %autosetup
) macro
in %prep
and adds -n
so the generated tarball can be unpacked. For this
purpose, it requires the name of the directory in the source archive. For tar archives
with one directory, Packit gets it automatically. If Packit is not able to extract it
from the archive with the tar python module, it is possible to specify it explicitly
with this option.
Default value is {upstream_pkg_name}-{version}
.
You can use following tags in string:
{upstream_pkg_name}
- name of the upstream package{version}
- package version
patch_generation_ignore_paths #
(list of strings) In a source-git repo, when packit is generating patches, it excludes changes to the spec file and packit.yaml by default: with this option you can precisely specify paths to exclude.
patch_generation_patch_id_digits #
(integer) The number of digits (minimum width) used for patch IDs when
adding PatchN
tags to a spec-file while updating dist-git from a source-git
repository. Defaults to 4, that is, patches will look like PatchNNNN: <patch_name>
, and leading zeros are added, if needed. A value of 0 means “no
minimum width”.
notifications #
There is only one notification configuration you can set up right now: enable the “Congratulations!” comment which will packit send after a successful build of a pull request is done.
The default behaviour is not to send the comment with instructions how to install a package with the change implemented in the pull request:
notifications:
pull_request:
successful_build: false
You can enable the commenting by setting successful_build
to true
.
issue_repository #
Use this key to be notified about errors of the downstream jobs (Koji build, Bodhi update, pull from upstream). The value can be a URL of any GitHub/GitLab/Pagure project including dist-git where issues are enabled and Packit has an identity on that git forger instance. Alternatively, you can set up a dedicated project for receiving such notifications. (Let us know if you need another instance to be supported.) It does not need to be an upstream repository, you can also enable an issue tracker for the dist-git repository and use this as a place for those notifications. Or, you can set up a dedicated project for receiving such notifications.
By default, no issue will be created so Packit doesn’t unintentionally spam any repository. (E.g. Since those jobs are defined in downstream, upstream project does not need to be aware of Packit.)
By enabling this setting, Packit will either create a new issue or add a comment to an already existing issue. In that case, the issue will be reused and a new comment will be added.
When a downstream job (e.g. Koji build or Bodhi update) fails,
you can re-trigger the failed job by
/packit koji-build
or /packit create-update
comment in the opened issue by Packit.
The Packit app has to be installed in the issue repository and the
user, who commented, needs to have write permissions
into the repository in order for the retriggering to work.
copy_upstream_release_description #
(bool) When doing a new update in Fedora dist-git, the GitHub upstream release description
is copied to the specfile changelog when set to true
. By default (false
),
commit message titles (first line of a commit message) are copied.
But be aware that the release description is copied as is, without any processing
and the result needs to fulfill the spec-file syntax.
Be specially careful when using characters like %
that can be interpreted as macros.
Also, use -
for bullet points instead of *
so the line is not interpreted as a new changelog entry.
e.g.
copy_upstream_release_description = True
:
%changelog
* Thu Oct 15 2020 Packit Service <user-cont-team+packit-service@redhat.com> - 0.18.0-1
Packit got new archive_root_dir_template config option to get custom archive root dir.
You can find more info in the documentation.
copy_upstream_release_description = False
(default):
%changelog
* Thu Oct 15 2020 Packit Service <user-cont-team+packit-service@redhat.com> - 0.18.0-1
- Use inner archive directory in %setup macro
- Use archive_root_dir_template
sources #
(list of dicts) A list of sources to override the URLs of SourceX
entries in the spec-file.
sources:
- path: rsync-3.1.3.tar.gz
url: https://git.centos.org/sources/rsync/c8s/82e7829c0b3cefbd33c233005341e2073c425629
path
is the path relative to the directory with sources where the source will be placed. If a SourceX
entry with
corresponding basename exists in the spec-file, the source will be downloaded from the url
found in the configuration
instead of the location defined in the spec-file.
srpm_build_deps #
(list of strings) A list of RPM dependencies that are needed for your actions to be run when building a SRPM. The dependencies are installed into the Copr build environment each time the build is triggered.
packit_instances #
(list of strings) If you want to help us with catching issues or need some feature sooner than other users,
you can use our staging instance that has the freshest code we have.
For that, you can specify the instance(s) that will react to your jobs by using this configuration option.
It uses ["prod"]
as the default, but you can set both (["prod", "stg"]
) or just stage (["stg"]
).
You can also have a different setup for each job – see how the overriding works
in the config file.
Just be aware that:
- You still need to install the staging GitHub application.
- Staging application has fewer resources and can be a bit slower in responses.
- If you use both instances, you will have twice the number of commit statuses.
- Picking just one instance might be better for downstream jobs since both instances will work with the production instances of Fedora systems.
Please, let us know when something looks weird or does not work with the staging app. By doing that, you are helping us to be sure that we don’t break your use-case.
Packit-as-a-Service #
Packit service doesn’t have any web interface to configure it, so the only way to change its behaviour is via the config file you just read about.
When you open a pull request against your upstream repository, packit service picks up configuration file from your pull request, not from the branch against the PR is opened. This way, you can polish your .packit.yaml and see the results right away. (for more info, please see packit-service#48)
Packit service jobs #
Once the service starts handling events of your repository, it needs to have a clear definition of what it should do.
The tasks the packit service should do are defined in section jobs
. The section is a list of dicts:
jobs:
- {key: value}
- {}
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
Every job has two mandatory keys:
job
- name of the job (you can imagine this as a CLI command)trigger
- what is the trigger for the job?
Every job only supports a specific set of triggers.
Overriding global parameters #
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
.
Aliases #
To not need to change the config file when the new system version is released, Packit provides multiple aliases to reference a subset of the active Fedora Linux releases:
fedora-all
- all active releases, which includes released and branched versions and Rawhide (e.g.fedora-34
,fedora-35
,fedora-36
,fedora-rawhide
).fedora-stable
— the current (two or three) released and supported versions (e.g.fedora-34
,fedora-35
).fedora-development
— development versions of Fedora; the branched version is used only when available (e.g.fedora-36
,fedora-rawhide
)fedora-latest
— the last versioned Fedora (not a Rawhide), regardless if it’s released or still under development.fedora-latest-stable
— the latest released Fedora version (e.g.fedora-35
).fedora-branched
— all branched releases, that is: everything, except Rawhide (e.g.fedora-34
,fedora-35
,fedora-36
).
Additionally, epel-all
can be used as an alias for the current active
EPEL versions (e.g. epel-7
,
epel-8
, epel-9
)
The aliases above can be used both to specify targets when building in
Copr or running tests, and to reference
dist-git branches of different system versions
(e.g. for propose_downstream
job
or downstream jobs like koji_build
or bodhi_update
).
The information about releases is retrieved from Bodhi and because of the cache and required availability on Copr, it might take a while to get the newest state.
Supported jobs #
copr_build #
Create a SRPM and submit an RPM build to Fedora COPR build system.
Supported triggers:
- pull_request – check out content of the pull request
- commit – reacts to new commits to the specified branch
- release – check out content of the tag associated with the release
Required parameters:
- targets - (a list of) mock chroot(s) where the build is going to be
executed (example
fedora-rawhide-x86_64
, defaults tofedora-stable
): for more info see below. Does not need to be defined if using a custom Copr project (we fetch targets from the Copr settings). - branch - the name of the branch we want to build for when using commit trigger
Optional parameters:
- timeout - (seconds) give up watching a build after timeout, defaults to 7200s, i.e. 2 hours
- owner - a namespace in Copr where the build should happen (defaults to packit).
Prefix with
@
in case of a group. - project - a name of the Copr project (defaults to
"{github_namespace}-{repository_name}-{pr_id}"
) - additional_repos - a list of additional buildroot repositories
- list_on_homepage – The project will be shown on Copr frontend homepage if set to
True
. Defaults toFalse
. The value is represented asunlisted_on_hp
in Copr project settings. - preserve_project – The project will not be removed after 60 days if set to
True
. Defaults toFalse
. The value is represented asdelete_after_days
in Copr project settings (True
is-1
andFalse
is60
). - enable_net – Specifies whether created Copr build should have access to network during its build.
Defaults to
False
(Copr default, switched toFalse
in June 2022). - identifier – Suffix added to the name of a GitHub check run. This is
useful when you have multiple
copr_build
jobs with different configuration. For example if you set this to “mock”, then a check run for Rawhide would be named “rpm-build:fedora-rawhide-x86_64:mock”. - module_hotfixes – The project will have
module_hotfixes=1
in the Copr generated repo files. This is useful when you build packages that need to be installed in a modular context. Defaults toFalse
.
Using a custom Copr project #
When using a custom Copr project (by specifying project
and owner
), the GitHub repo has to be listed in the
Packit allowed forge projects field in the Copr project settings so that the Copr builds can be actually run.
As an example the string github.com/osbuild/osbuild has to be inserted
into https://copr.fedorainfracloud.org/coprs/g/osbuild/osbuild/edit/#packit_forge_projects_allowed.
When using a custom owner
, Packit Service asks for builder
permission the
first time it tries to build in the project. In case the configuration of the
Copr project (e.g. adding new targets
) need to be updated, Packit Service asks
for admin
permission. You need to approve these requests in the Copr project
settings.
If you do not want to give us admin
permission, you can update the project
settings manually in Copr based on the guidance Packit Service gives.
You can also directly edit the permissions yourself without waiting for the Packit request by running:
$ copr-cli edit-permissions --builder packit [--admin packit] <project>
Boolean values (list_on_homepage
and preserve_project
) are not updated when
you use custom owner
.
Example
jobs:
- job: copr_build
trigger: pull_request
targets:
- fedora-stable
- centos-stream-8-x86_64
With this configuration, you’ll get builds in all stable fedora releases (excluding rawhide) and the CentOS stream.
Target-specific configuration #
You can define a specific build configuration for different targets (chroots in context of Copr). For example, there are packages that are architecture specific and not available for all architectures. Or you may want modules enabled for builds in CentOS Stream 8.
Copr allows specifying additional packages, modules and repos for individual targets.
Setting this in packit.yaml requires targets to be a mapping. If you require this functionality, this is the preferred solution over specifying multiple jobs. Example:
jobs
- job: copr_build
trigger: pull_request
targets:
centos-stream-8:
additional_repos:
- http://koji.katello.org/releases/yum/foreman-nightly/el8/x86_64/
additional_modules: "foreman:el8,ruby:2.7,nodejs:12,postgresql:12"
fedora-rawhide: {}
fedora-37: {}
In this case, both Fedora targets don’t have anything specific and would use packages and modules from the base distro, while CentOS Stream 8 will use a custom yum repo and 4 specific modules.
You can define these three options:
additional_packages
(list) – install additional packages before the buildadditional_repos
(list) – enable these yum repositories before installing any packagesadditional_modules
(str) – enable these modules before installing packages, specified as comma-separated string:MODULE:STREAM,MODULE2:STREAM2,...
Available COPR build targets #
There are multiple places where you can get the latest list of available build targets:
-
Open your COPR project, then click “Settings” > “Build options” > “Chroots” - these are the same values packit accepts.
-
Install package
copr-cli
and run:
$ copr-cli list-chroots
centos-stream-8-aarch64
centos-stream-8-x86_64
custom-1-i386
custom-1-x86_64
epel-6-i386
epel-6-x86_64
epel-7-aarch64
epel-7-x86_64
epel-8-aarch64
epel-8-x86_64
fedora-32-aarch64
fedora-32-armhfp
...
-
You can also use the aliases provided by Packit to not need to change the config file when the new system version is released.
By default, the
x86_64
architecture will be used, but you you can override the default e.g.fedora-stable-aarch64
. -
If you are using custom Copr repository for your Copr builds, you don’t have to define the targets at all and they will be deduced from your custom Copr project.
tests #
See more about tests here.
upstream_koji_build #
Create a SRPM from upstream and submit a scratch RPM build to Fedora Koji build system.
At the moment it is not possible to run non-scratch Koji builds from upstream. For more info, please see the following issue.
If you want to do official Koji builds, the sources need to be present in
dist-git: job koji_build
can take care of that.
(The job used to be called production_build
but we are deprecating that name in favour of
the more explicit upstream_koji_build
.)
Supported triggers:
- pull_request – check out content of the pull request
- commit – reacts to new commits to the specified branch
- release – check out content of the tag associated with the release
Required parameters:
- branch – the name of the branch we want to build for when using commit trigger.
Optional parameters:
- targets – (a list of) targets we want to build for,
list of supported targets can be listed using with
koji list-targets
. You can also use the aliases provided by Packit to not need to change the config file when the new system version is released.
propose_downstream #
Land a new upstream release in Fedora. This job only makes sure the changes happen in Fedora dist-git - no builds. A pull request is created as a result.
Supported triggers: release.
Optional parameters:
- dist_git_branches - a (list of) branch(es) in dist-git where packit should work (defaults to
main
). You can also use the aliases provided by Packit to not need to change the config file when the new system version is released.
Example
jobs:
- job: propose_downstream
trigger: release
- job: propose_downstream
trigger: release
dist_git_branches:
- f35
This config would update Fedora Rawhide and Fedora 35 dist-git branches.
If you need to do any change in the pull request, you need to locally fetch the source branch of the Packit’s pull request and push it (with a fix) to your fork (as it is not possible to push to the branch created in the Packit’s fork):
git fetch ssh://$USER.fedoraproject.org/forks/packit/rpms/$YOUR_PACKAGE.git refs/heads/*:refs/remotes/packit/*
git cherry-pick packit/$VERSION-$BRANCH-update-propose_downstream
pull_from_upstream #
A dist-git only job that opens a new dist-git pull request in src.fedoraproject.org when a new upstream release happens using a notification from release-monitoring.org.
This job utilizes the same logic as propose_downstream
with the only
exception that it is defined and executed in dist-git.
Use issue_repository
option to get information about
possible failures during the update process.
Requirements:
- The job is defined in a Packit config in the default branch of the dist-git
repository (
rawhide
). Packit configs on other branches are ignored. - Upstream release monitoring is active for the package. The monitoring
status
in dist-git should be set to
Monitoring
). upstream_project_url
is defined in the configuration.
Upstreams (defined in upstream_project_url
) hosted in these Git forges are currently supported: https://github.com, https://gitlab.com, https://gitlab.freedesktop.org,
https://gitlab.gnome.org, https://salsa.debian.org.
Support for working with upstreams in all Git forges is planned to be
worked on shortly (see).
Supported triggers: release.
Optional parameters:
- dist_git_branches - a (list of) branch(es) in dist-git where packit should work (defaults to
main
). You can also use the aliases provided by Packit to not need to change the config file when the new system version is released.
Example
upstream_project_url: https://github.com/packit/packit
...
jobs:
- job: pull_from_upstream
trigger: release
dist_git_branches:
- fedora-all
- epel-9
Once a new upstream release happens, Packit will open a pull request with it in all active Fedora releases and EPEL 9.
If you need to do any change in the pull request, you need to locally fetch the source branch of the Packit’s pull request and push it (with a fix) to your fork (as it is not possible to push to the branch created in the Packit’s fork):
git fetch ssh://$USER.fedoraproject.org/forks/packit/rpms/$YOUR_PACKAGE.git refs/heads/*:refs/remotes/packit/*
git cherry-pick packit/$VERSION-$BRANCH-update-pull_from_upstream
For more details, check our release guide.
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 newly pushed commit.
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
.
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
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 retriggering the job, see our release guide.
For Koji builds from upstream, see upstream_koji_build
.
Supported triggers:
- commit – reacts to new commits to the specified branch (in dist-git)
Required parameters:
- 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.
Optional parameters:
- 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
(defaults to
['packit']
). - allowed_committers - a list of FAS accounts of committers whose pushes to dist-git will trigger koji builds (defaults to an empty list).
Example
jobs:
- job: koji_build
trigger: commit
dist_git_branches:
- fedora-all
- epel-8
bodhi_update #
Create a new update in Fedora Bodhi for successful Koji build. 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 commit the build is triggered from.
For now, the Bodhi update is created only for builds submitted by the Packit FAS user.
(See koji_build
job for more details on how to set this up.)
This is just for the early stage of this job, and
we can easily turn off that filter.
Let us know if you need this condition to be removed.
There is no UI provided by Packit for the job, but it is visible across Fedora systems like a manually created Bodhi update, and you can utilise Fedora Notifications to tweak the notifications settings.
For retriggering the job, see our release guide.
Note that this job is really new and not mature yet – let us know if you find anything problematic or any improvement we can implement.
Supported triggers:
- commit – Packit uses the original action as a config trigger, so you need to use
commit
as a trigger. The real trigger is a successful Koji build (that was triggered from a commit).
Required parameters:
- dist_git_branches – the name of the dist-git branch(es) the build we want to use is coming from. You can also use the aliases provided by Packit to not need to change the config file when the new system version is released.
Example
jobs:
- job: bodhi_update
trigger: commit
dist_git_branches:
- fedora-stable # rawhide updates are created automatically
- epel-8
vm_image_build #
Supported triggers:
- pull_request
Image Parameters (Packit does not sanitize these and just passes them to Image Builder; check Image Builder’s API documentation for details).
- image_request – values passed to the “image_requests” field of Image Builder’s API
- image_customizations – values passed to the “customizations” field of Image Builder’s API
- image_distribution – name of the “base image” (examples: rhel-90, fedora-36)
Required parameters:
- copr_chroot – name of the chroot to use for installing packages in the image
- owner – Copr project owner
- project – Copr project name
Image builds are only triggered after a collaborator places a comment /packit vm-image-build
in a pull request. The image builds are NOT submitted
automatically. This is a subject to change as we improve the integration in future.
Example
jobs:
- job: vm_image_build
trigger: pull_request
image_request:
architecture: x86_64
image_type: aws
upload_request:
type: aws
options:
share_with_accounts: ["123456789"]
image_customizations:
packages: [foo-bar]
image_distribution: fedora-36
owner: john-foo
project: foo-bar-martini
copr_chroot: fedora-36-x86_64
User configuration file #
When running packit as a tool locally, it is convenient to use a configuration
file to provide data such as API tokens. Packit respects XDG_CONFIG_HOME
environment variable. If not set, it looks inside ~/.config/
directory.
The acceptable names are the same as for the package config:
.packit.yaml
.packit.yml
.packit.json
packit.yaml
packit.yml
packit.json
Values #
Key name | Type | Description |
---|---|---|
debug |
bool | enable debug logs |
fas_user |
string | username in Fedora account system; this is utilized when authenticating with Bodhi using Kerberos |
kerberos_realm |
string | Kerberos realm to use for authentication, example “FEDORAPROJECT.ORG” |
authentication |
dict | tokens for services (GitHub, Pagure) |
upstream_git_remote |
string | name of the git remote to discover upstream project URL from |
redhat_api_refresh_token |
string | Red Hat API token, can be obtained here |
The authentication
is a dictionary where:
- key is a hostname, url or name that can be mapped to a service-type, for example
github.com
orpagure
- value is a dictionary with keys:
token
andinstance_url
(optional)
e.g.:
authentication:
github.com:
token: mnbvcxz123456
pagure:
token: qwertyuiop098765
instance_url: https://src.fedoraproject.org
The GitHub token is needed when packit interacts with GitHub API, get it at https://github.com/settings/tokens (getting full read & write repo scope should be enough). The Pagure token needed to access REST API, get it at https://src.fedoraproject.org/settings#nav-api-tab
Specifying tokens as direct keys github_token
and pagure_user_token
has been deprecated and will be removed in future versions.
Since API tokens are a very sensitive information, please do NOT ever store them in a public (such as a GitHub repository). The configuration file here is located on your workstation, please do NOT confuse it with a config file for your project - that one is described above in the first section of this document.