Were you annoyed by Packit creating divergent branches in your package's dist-git repository? You'll be happy to know that Packit now supports a new dist_git_branches syntax that enables fast-forwarding commits between branches.
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.
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.
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.
Fedora EL Niño (ELN) is such an awesome idea. It enables building rawhide packages in two distinct buildroots:
This way you can make sure that your new upstream release builds fine in the next RHEL.
