Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CentOS Stream support #2106

Open
3 of 12 tasks
lbarcziova opened this issue Jun 29, 2023 · 10 comments
Open
3 of 12 tasks

CentOS Stream support #2106

lbarcziova opened this issue Jun 29, 2023 · 10 comments
Labels
complexity/epic Lost of work ahead, planning/design required.

Comments

@ckelleyRH
Copy link

ckelleyRH commented Nov 24, 2023

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. 😆 If you guys do this, you will get auto-carnage in additional to the current manual carnage.

@mfocko
Copy link
Member

mfocko commented Nov 24, 2023

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
Copy link

Sounds good!

@lachmanfrantisek
Copy link
Member

@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
Copy link
Member

@ckelleyRH thanks for the suggestion!

@lachmanfrantisek
Copy link
Member

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

@lsm5
Copy link

lsm5 commented Mar 20, 2024

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
Copy link
Member Author

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
Copy link

lsm5 commented Mar 20, 2024

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
Copy link
Member

mfocko commented Jul 17, 2024

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

prestist added a commit to prestist/coreos-installer that referenced this issue Aug 20, 2024
While releasing coreos-installer, we found that the current
CentOS packaging did not introduce enough benefit to outweigh
the process change required to keep other repos consistent.
We will revisit once additional support is added for running
builds/tests/ticketing.

Ref: packit/packit-service#2106
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity/epic Lost of work ahead, planning/design required.
Projects
Status: in-progress
Development

No branches or pull requests

5 participants