search

packit / packit-service

Packit provided as a service
https://packit.dev
MIT License
37 stars 48 forks source link

CentOS Stream support #2106

Open lbarcziova opened 1 year ago

lbarcziova commented 1 year ago

Related

Possible users / uscases

ckelleyRH commented 11 months ago

UX suggestion/warning:

Whatever you do, when you propose a PR/MR to CentOS Stream in the gitlab.com/redhat namespace, DO NOT use any branch names of the form rhel-*.

TL;DR - These are protected branches in origin, and there is a bug in GitLab that prevents the Stream pipelines from running if the remote branch name shadows a protected branch. Stream maintainers keep crashing into this, because naming your branch after the issue you are trying to fix is an entirely reasonable thing to do isn't it. :laughing: If you guys do this, you will get auto-carnage in additional to the current manual carnage.

mfocko commented 11 months ago

I think it shouldn't be a problem, right now we use:

$version-$chroot-update-$job_type

and we were considering leaving out the $version for the sake of not spamming with PRs… if it came to the worst, I guess we could prefix it with packit, so there would be something like:

packit/$version-$chroot-update-$job_type
$job_type ∈ { pull_from_upstream, propose_downstream }
ckelleyRH commented 11 months ago

Sounds good!

lachmanfrantisek commented 11 months ago

@mfocko I am for the prefix. It's similar to what pre-commit is doing (i.e. the pre-commit-ci-update-config branch)

lachmanfrantisek commented 11 months ago

@ckelleyRH thanks for the suggestion!

lachmanfrantisek commented 10 months ago

We want to aim for a couple of projects to be onboarded for the next quarter. The number is yet to be decided.

lsm5 commented 8 months ago

We want to aim for a couple of projects to be onboarded for the next quarter. The number is yet to be decided.

@lachmanfrantisek what's the latest on this? and include us please :)

EDIT: C9S could be a problem for us given the lack of %autorelease and %autochangelog, but if this will also include c10s whenever that releases, we'd be all for it.

lbarcziova commented 8 months ago

hi @lsm5 ! We have the initial support for propose_downstream and this is described in the documentation here: https://packit.dev/docs/configuration/upstream/propose_downstream#syncing-the-release-to-centos-stream. We will be happy if you will try that out! You can configure the branches similarly as for Fedora (see the example). Which repositories would you be interested in onboarding?

Besides that, support for pull_from_upstream is being implemented as well in #2068.

lsm5 commented 8 months ago

hi @lsm5 ! We have the initial support for propose_downstream and this is described in the documentation here: https://packit.dev/docs/configuration/upstream/propose_downstream#syncing-the-release-to-centos-stream. We will be happy if you will try that out! You can configure the branches similarly as for Fedora (see the example). Which repositories would you be interested in onboarding?

I will defer to @jnovy as he's our main centos and rhel guy, but I think we should be safe to enable this for the c10s branches for these packages: aardvark-dns, buildah, container-selinux, crun, netavark, podman, skopeo

There might be more down the line, but I think we can start with these.

mfocko commented 4 months ago

Update

We have planned #2068 as a complexity/single-task card, yet it appears that it requires much more work than has been anticipated. Given that, it makes more sense to keep #2068 as the epic for the release-sync to CentOS Stream as any other subtasks of this epic are more related to further improvements to the user experience (e.g., Jira or vetting) with running Packit for CentOS Stream rather than the release-syncing itself.

providing an update with regards to the recent Q3 planning; cc @lachmanfrantisek