Have you ever wanted to bring your pull request changes in a cloud image easily?
Curious about how easy it can be? With Packit, it can be just about commenting on your pull request with /packit vm-image-build.
With the above command, Packit automates all the manual steps needed to create an RPM package with your pull request changes and asks the Image Builder to install it inside a brand new cloud image. Let's have a look at the prerequisites for this.
Have you ever wanted to make changes in an RPM spec file programmatically? specfile library has been created for that very purpose. It is a pure Python library that allows you to conveniently edit different parts of a spec file while doing its best to keep the resulting changeset minimal (no unnecessary whitespace changes etc.).
"How absurdly simple!" I cried.
"Quite so!" said he, a little nettled. "Every problem becomes very childish when once it is explained to you."
We have planned for a while to use Packit to generate packages on Copr on demand for our somewhat complicated Rust executable, stratisd. It looked like this was going to be challenging, and in a sense it was, but once the task was completed, it turned out to have been pretty straightforward.
In the upcoming months, we plan to migrate our service to a new cluster. However, this may affect propose_downstream
and pull_from_upstream jobs due to the new firewall rules. The problematic aspects could be:
actions during syncing the release involving interactions with external serversTo smoothen this transition, we kindly encourage you to enable one of these jobs on our already migrated staging instance. This recommendation is particularly important if you belong to one of the groups affected by the two previous points. This proactive step will help us identify and address any issues promptly.
Recently, we received multiple contributions from the Strimzi team, specifically Jakub Stejskal and David Kornel, for the functionality of manual triggering of jobs and other related improvements, mostly focusing on the testing UX. We are very happy about these and would like to showcase the results of their awesome contributions.
We are very happy to announce a major enhancement to Packit! We have now added support for monorepositories, enabling the integration of upstream repositories containing multiple downstream packages. If you have a repository in the monorepo format, Packit can now help you automate the integration to downstream distributions both from CLI and as a service.
We have recently made some fixes to the process of handling the Release field regarding the %autorelease macro, so let's take that opportunity to explain how it works.
pre-commit is a wonderful tool that saves you a lot of time by automatically checking your changes before you commit and/or push them out.
As you will see in the following paragraphs, the year 2022 was really fruitful for the Packit project. Without further ado, let’s take a look at what the Packit team accomplished last year!
In the previous year, we automated the Fedora downstream release process in Packit.
The first step of the release process, propagating the upstream release to Fedora,
is covered by the propose_downstream job.
This job updates the sources in Fedora, the spec file, and other needed files and creates pull requests with the changes
in the dist-git repository.
The downside of this job is that for its execution, users need to install Packit Service GitHub/GitLab app since this job reacts only to GitHub/GitLab release webhooks. However, the person who maintains the package in Fedora may not be the upstream maintainer and may not have admin access to the upstream GitHub/GitLab repository.
To cover this case, we came up with a new job called pull_from_upstream, which aims to update Fedora dist-git similarly
to propose_downstream, but is configured directly in the dist-git repository.
Let's now look at how to set it up and how it works.
