On Wed, Jul 30, 2025 at 1:01 PM Kevin Fenzi <ke...@scrye.com> wrote: > > On Wed, Jul 30, 2025 at 03:44:05PM +0200, Miro Hrončok wrote: > > > > Let's have draft builds like in CentOS Stream? > > > > A pull request is scratch built anyway. Let it build as draft build and when > > the PR is merged, promote the draft build to a real one (in a side tag if > > needed). > > Are there any docs or description of the full flow there?
Define "the full flow" please? The basics are: * The merge request is submitted and a request for draft build testing is made (today while it's in "Beta", this is a Gitlab MR label, in the near future this will just become the default for all MRs) * The CI pipeline starts to run, generating a draft build in CS Koji (and internally in RHEL's Koji infrastructure). * The completed draft builds are used to run a series of acceptance tests. If all of them pass, the pipeline grants approval and the packager can merge. (If the pipeline doesn't grant approval, someone other than the packager must do so if they need to override the decision). * The package hits the merge button and another pipeline (called a "merge train") begins. This one runs a few final sanity checks (like verifying that we haven't transitioned from "development" to "stabilization" phase and requires more stringent approvals) and then "promotes" the CS and RHEL draft builds to official ones. Then the merge completes. > I mean, there's a bunch of corner cases... like you have 5 PR's (so I > guess you merge one and the rest make new draft builds and the next one, > etc). > > But yeah, we could figure out a setup there... > That's an extreme corner case for packaging, since it's quite rare to have two people working on independent merge requests to update a package. The solution there is to have the git forge require only fast-forward merges, which means that once one is merged, the others will be non-mergeable until they rebase (which will create a new draft build). In the extremely unlikely event that there's more than one waiting in the wings, the merge of the first one should be a clear signal that the remainder should be coordinated so as not to generate too many useless draft builds. Such multiple PRs are far more common on upstream packages. So for us (Fedora), the most likely places to have to deal with that would be things like SRPM macros, where the package IS the upstream. We may want to have a separate policy for those. It's an interesting question. But those are definitely the exception, rather than the common case. -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
