[WIP] Update Mass Branching SOP #489
No reviewers
Labels
No labels
obsolete
rerwite-required
SOP
untriaged
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
infra/docs!489
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "patrikp/docs:sop_mass_branching"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
9955edb238to707027bf24Is this ready for review? Or do you have more changes to push first?
For the openh264 section at the bottom. It's a mish mash currently. Remove all that and replace with:
( where 45 is the new rawhide version).
UPDATE repository_redirect SET to_repo = regexp_replace(to_repo, '-44$', '-45') WHERE from_repo ILIKE '%openh264%';
It's not ready for review yet, I would like to format it better, the information is there but some of it is pretty chaotic. I'll be sure to tag you once it's ready for review/feedback.
Some notes from my perspective:
The fedfind release metadata should be updated just before we fire the new composes. I'm pretty sure now that's the least-bad time to do it.
We should ensure Bodhi has a critpath file for the new branched release BEFORE any new updates can be created for the newly-branched release. You can see what critpath files it currently has by rsh'ing into any running Bodhi container and looking in
/etc/bodhi/critpath. The files for current Rawhide are namedrawhide*, they are not named by release number (I should try and remember why, actually). The files for all other releases are named by release number. We need the files for the new Branched number to exist, or else Bodhi won't consider any updates to be critpath so nothing will be gated.There are a few details here. We can wait till we can do a real critpath generation - which means the new Branched compose has to run and be synced out first, then you can run an
occommand to manually trigger the generation. Or we can, in some way, just copy the previous Rawhide data to the newly-branched release number at some point - we could do this as a one-off special action at branch time somehow, or we could adjust the script to just always copy the 'rawhide' files to the current Rawhide release number as well, that should be safe.Also, do we keep Koji blocked until this is done, or do we unblock Koji but try to block Bodhi somehow until it's done?
OK, based on a suggestion by @kevin , releng/tooling#13022 should solve the critpath issue - with that, we'll just keep using the most recent Rawhide critpath data for the new Branched release until such time as we manage to do a successful new critpath generation run after the branching.
Oh, also, we should improve the mirrormanager instructions. Linking to a random pagure issue with old release numbers isn't great, and it's missing info on how to get into the database in the first place. We didn't quite do it right this time around so clearly the instructions/procedure aren't good enough.
Ideally it would be ansiblized somehow, if not, there should be better instructions in-line in the doc, with the release numbers correctly templated and details on how to get into the correct db.
Couple of repo issues that showed up: fedora-openh264 repo for Rawhide was 404 for a while (this seems fixed now, I guess @kevin fixed it?) and fedora-updates-archive repo for F44 is 404 currently. These both should be sorted at branch time as they break openQA ostree tests (rpm-ostree seems to treat all repos as critical and fail if any is unreachable).
Yeah, I did fix the openh264 rawhide repo (well, I made an empty one).
For updates-archive, thats @dustymabe
From @dustymabe for updates-archive:
the steps for adding a new RELEASE stub is in the README under
Rough notes for initializing the archive repo from scratch. The keys to the bucket were given to us by releng.adamwill referenced this pull request from quality/tickets2026-02-07 20:11:10 +00:00
@ -464,3 +485,3 @@[source,bash,subs="attributes"]----$ koji list-builds --state=0 --type=rpm | grep fc{branched} | awk '{print $1}'$ koji list-builds --state=0 --type=rpm | grep fc{rawhide} | awk '{print $1}'This really depends, as I mentioned this before, we always update the attributes before the branching happens, and we don't need to go through the hassle of changing variables; instead, this adds in T-1 day about updating the attributes; it should be a branched tag only that we need to cancel.
@ -590,1 +621,3 @@$ bodhi releases edit --name F{branched}F --eol YYYY-MM-DD$ bodhi releases edit --name F{rawhide} --eol YYYY-MM-DD$ bodhi releases edit --name F{rawhide}F --eol YYYY-MM-DD$ bodhi releases edit --name F{rawhide} --branch f{rawhide}I think again, with the above confusion,n we need to set the date of branched release, not the rawhide. +1 on removing the unwated releases
@ -706,0 +698,4 @@- `pungi-fedora`- `fedora-kiwi-descriptions`- `fedora-comps`- `workstation-ostree-config`I recommend merging this as an inital step for The T day of branching
707027bf24tofee25ac50dAnother thing I found: fedora-appstream-metadata should be updated at branch time, see https://bugzilla.redhat.com/show_bug.cgi?id=2440511 . Tagging @siosm
Ooh, another thing: we should add a run of the
openqa.ymlplaybook with-t testcase_statsto the steps once theFedoraBranchedvariable is set true.fee25ac50dto6e6e163969Hey @patrikp, just a heads up that I've opened PR #496 to remove dead PDC references across the docs (Issue #344). I specifically avoided touching
modules/release_guide/pages/sop_mass_branching.adocto ensure I didn't cause any merge conflicts with your rewrite here. Good luck with the chaos ; )View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.