We are happy to announce that support for non-git upstreams in the pull_from_upstream job is here! This enhancement simplifies configuration by removing the need to define upstream_project_url, opening the door for more use cases, while also simplifying the onboarding in general.

It’s been a month since two Packit members (Laura and František) attended Flock, the annual Fedora conference, in Rochester. Let’s see some highlights from our journey There and Back Again. Sadly the travel there wasn’t as expected at all, but luckily the tornadoes did not stop us and we both made it to Rochester.

We are excited to announce a new experimental feature in our service: the integration of Static Application Security Testing (SAST) using OpenScanHub.

OpenScanHub is a service that runs various static analyzers on RPM packages - by default Cppcheck, ShellCheck and the static analyzers embedded in GCC.

Let's have a look at the details of the prototype!

Last month, we had the pleasure of engaging with a dynamic audience during our interactive talk on changelogs at the DevConf in Brno, Czech Republic. In case you missed it, you can watch the recording here. Throughout the session, we explored various aspects of changelog usage, including their content, format, and the potential for automation. By asking a series of questions to the attendees, we gathered insights and opinions that highlighted both common practices and divergent viewpoints within the community. In this follow-up article, we aim to summarise the key findings from our discussion, analyse the trends and preferences that emerged, and offer our reflections on the role of changelogs in software development.

The first part of June is usually quite busy for our team. Why? The last couple of years, this has been a time of DevConf.CZ conference. (The unpredictable January had been changed into a more pleasant June.) Even though the conference itself is important, it’s used as an opportunity for various people from around the globe to come to Brno and thanks to that, a lot is happening also during the days around. For the Packit team, it’s a nice opportunity to have the whole team together in one place – we can do some fun teambuilding (like canoeing this year) but also discuss any technical topics or meet our users and realise how are the real people behind all the nicknames. This time we also prepared something for them:

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."

• Arthur Conan Doyle, "The Adventure of the Dancing Men"

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:

• commands you run in your actions during syncing the release involving interactions with external servers
• downloading your sources from various hosting services (crates.io, npm, gems, etc.)

To 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.