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.

Packit contributions

We prepared two talks for the Flock attendees. If you missed it, the recordings are available. But here’s what we presented:

Packit release automation journey​

This one mainly targeted the Fedora maintainers and described how you can use Packit for your packages. The basic workflow has been here for some time but we’ve presented a couple of interesting news about what we are currently working on:

The requirement to have a git repository representing is now gone. By NOT specifying the upstream_project_url config option, Packit will not try to clone or interact with the upstream via git. This is especially useful if the upstream project does not use git, or you just don’t need it (e.g. packages using language-specific repositories like PyPI).

If you are interested in having a nice git tree, you’ll welcome that the Packit team is currently working on making it possible to avoid diverging branches when doing release syncing.

Another long-time-awaited feature is support for releasing package groups using side-tags. Since Flock, Nikola from the Packit team polished the functionality and even created a dedicated documentation pagee describing how to use it.

And that’s not all, there are also two related efforts we are in the early phases. One is about using Packit to run reverse-dependency checks/builds. The update is that Mikolaj Izdebski (thanks a lot!) re-enabled a Copr plugin in Koschei so it should now be possible to run the checks independently to Koji which is better for ad-hock CI checks but also to not produce extra load on Koji itself. Ideally, this would be available for both upstream and dist-git pull requests. And speaking of the dist-git pull requests, there is a discussion about the future of Fedora CI and Zuul, we agreed within a team to take a look and see if we can’t help with that. The reasons and questions to answer are covered in the talk.

And that’s still not all. There is also a Google Summer of Code project by Bryan Elee as part of which an integration for OpenBuildService is being implemented. Stay tuned. The CLI support is nearly there.

And lastly, project Myccorhisa. Our effort to create a unified dashboard for various Fedora-related services. Want to help us better understand the needs? Please, describe your usual workflow in this form.

But we were not speaking just about the features but also how we work and how we help people to get on board.

After the talk, there was an interesting discussion. One of the suggestions was to onboard new packages to Packit automatically – we thought about it within a team and will work on opening a pull request with the configuration and most importantly, a description of Packit.

Packit + Testing Farm and Fedora: still happily testing upstream projects​

For the second talk, we were joined by Jan Havlín from the Testing Farm team and the main aim of the talk was to show various new and old ways how to use Packit for your project. Rather than showing documentation, we presented the features on real projects and how they configure this so you can easily do the same. You might have seen this style of presentation from us, but don’t be fooled just by the structure, there were a couple of new features presented as well.

One big achievement is a collaboration with Siteshwar Vashisht on integrating OpenScanHub to run static analysis for your projects. The setup is very simple, just set up Packit to run builds both for the pull requests and your main branch and Packit will trigger a differential scan on pull requests for you. We have a separate blog post (/posts/openscanhub-prototype) about this. There is also one written by Situ.

Also, Jan showed how you can newly generate your own Testing Farm tokens using your Fedora account – but when using Packit, this is not needed and Packit will take care of this for you. But maybe you want to use this to play with the Testing Farm environment locally – you can newly reserve a machine thanks to this token.

Other talks and activities

During the Flock, we’ve quite intensively discussed the possibility of running Packit in Fedora infrastructure. Why? Currently, Packit is run on a RedHat-hosted OpenShift instance, but Packit’s main target is Fedora and we don’t communicate (and also don’t want to) with Red Hat internal services. Also, to show clearly the users that Packit is part of Fedora. On this topic, there was a talk held by David Kirwan about Communishift which is here for users to deploy their projects on Fedora-hosted OpenShift. We can use it, but we discussed with CPE team, that OpenShift managed by CPE team and used for other Fedora infrastructure systems might be a better fit. Matej Focko from our team collected our requirements and we were asked to communicate this publicly via https://discussion.fedoraproject.org.

A lot of interest was caught by the talk about Fedora dist-git forge replacement. Tomáš Hrčka quite nicely covered the current state that his team was asked to do the technical research but did not make any decision. Packit has even been included in their research which we are thankful for. Currently, we have two candidates – Forgejo and GitLab. Both have been deployed for testing purposes and can be accessed via Fedora staging accounts. So far, the Forgejo seems like a better choice both because of extensibility and ease of deployment/maintenance but nothing has been decided yet. There are two Packit-related topics – if Forgejo is picked, we need to implement its support in ogr, our library for git-forge communication, but hopefully, this would be the only place for change, let’s see…;) Another interesting thing is that there is an idea to provide dist-git functionality not directly on the git-forge, but as a separate dashboard/page and this might be worth collaborating as part of the project Myccorhisa.

If you are interested in testing in Fedora, you must watch the talk by Adam Williamson with a long title The hard problems: towards stronger checks on dependencies and compose inputs in Fedora. Hopefully, Packit be a part of the solution covered during the talk.

Thanks to the community aspect of the conference, it was really easy to sit down with anyone and help them with the Packit setup and we’ve managed to onboard a couple of new projects for Fedora automation. Usually, people want to do the onboarding at home, alone (which they hardly do) at first, but they are happy to leave with a working setup after a bit of convincing. We can unblock them more easily, and describe anything needed and they are usually surprised at how simple it is..;)

If you are interested in a talk that was really engaging, take a look at CentOS Stream - a preview of RHEL, a solid base for CentOS SIGs by Adam Šamalík. It was a nice walkthrough covering CentOS Stream and its design and processes. Also, a couple of interesting questions followed.

We also attended the Fedora Infrastructure Hackfest. There were a lot of topics covered, but two had a relation to Packit:

• There is a plan to unify the building of containers across CPE and we’ve suggested to include more teams like Packit since this is not a unique problem. A group of interested people will collaborate on the documentation and tooling.
• There are a lot of packages owned by the infra-sig and it’s hard to maintain them all. A cleanup is needed (e.g. pass the packages to other relevant parties). For the basic packages, we proposed help with Packit onboarding.

There were many more discussions and talks worth mentioning. Feel free to check the schedule with links to YouTube videos from the recording.

Will we meet next year?

Could not make it in person this year? Let’s hope we’ll meet next year. Maybe somewhere in Europe this time. Want to influence the future Flock? There is still a day to fill out the Flock Survey.

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.

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.