When a specfile is being generated, and both specfile_path and
downstream_package_name are not set, Packit now correctly resolves this
situation and sets specfile_path to the name of the upstream repo suffixed
A new command packit source-git status has been introduced for checking
the synchronization of a source-git and a dist-git repository based on the
used git trailers. The command outputs a range of commits which need to be
synchronized from dist-git to source-git or the other way around. If possible,
the command also provides instructions on how to synchronize the repositories.
We have added a new enable_net configuration option for Copr builds that
allows you to disable network access during Copr builds. It is also complemented
by --enable-net/--disable-net CLI options if you use Packit locally.
Progress of propose-downstream is now saved in the database and is available
via API. Visualization in the dashboard is to follow next week, stay tuned.
When running tests for the pull-request job, we now expose environment
variables for commit hash, branch and URL both for pull-request source and
target. In the test environment, you can use the following variables:
PACKIT_SOURCE_SHA, PACKIT_TARGET_SHA, PACKIT_SOURCE_BRANCH,
PACKIT_TARGET_BRANCH, PACKIT_SOURCE_URL and PACKIT_TARGET_URL.
These variables are not set for test runs of releases and branch pushes.
You can view information about ongoing propose-downstream jobs via our dashboard.
We have switched the cache for dist-git branches and Copr targets to TTL cache
that gets discarded once in 12 hours, in case there is a change in targets, the
changes shall propagate to both of our deployments without the need to redeploy
within 12 hours. (packit#1513)
Packit now comments when it fails to find Copr project specified in the config.
Packit now reacts to dist-git pushes to either rawhide or main when configured
to do Koji builds for rawhide.
You can specify an identifier for your job to be able to configure one job multiple times.
For example, you can build multiple projects from one repository (known as monorepo concept)
or try multiple build options. Using identifiers allows Packit to avoid naming collisions
in commit statuses and default Copr project names.
Packit no longer provides a misleading comment when it fails to update a set of
targets on its own Copr projects.
When using Packit CLI for creating Bodhi updates,
you can now set fas_username and fas_password in your Packit user config
to not be asked about that when the command is executed.
Also, this allows Packit GitHub application to use this as well
so you can look forward to Bodhi updates created by Packit
(will be announced and described in a dedicated post).
Interactions with Bodhi should be now more reliable when creating Bodhi updates.
Packit will no longer error out when trying to create a new Copr repository
when it is already present.
There is a new packit_instances key that you can use to specify the Packit
instances you want to use for working on your jobs. Nothing will change for our
production users, but users of our stage instance need to use this key to
preserve the support of the stage instance – they can set both stg and prod in
the packit_instances list to use both, or use just one. Just be careful with
the downstream jobs where both instances work with the same services.
This new option works like other Packit options so you can set it on the top
level and/or (re)define it on the job level.
More information about our staging instance can be found here: