4 posts tagged with "pull-from-upstream"

There are upstream projects that have multiple release streams and, for example, regularly release patch versions for every active minor version. With pull-from-upstream you have been able to follow only the highest stream, but that now changes. By switching Monitoring status of your package from Monitoring to Monitoring all, you enable triggering pull-from-upstream for every released version, not only the highest. This means you can use options such as version_update_mask, upstream_tag_include or upstream_tag_exclude (those require upstream_project_url to be set) to filter a specific release stream you want to follow, or have multiple pull-from-upstream jobs, each matching different releases and targeting different dist-git branches.

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:

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