testing branches TODO/idea

[renner0e]

(make this into a table/flowchart where appropriate and put in CONTRIBUTING.md)

• all PRs go to main, building :testing images, source of truth

• stable release branch must have a temporary/increasing name, naming like stable-f44 (very bikeshedable), branching from main for a new version

• stable release branch builds :latest and :stable

• renovate updates everything, excluding common and brew for stable release branch (features in our control that break stuff), this means that :latest and :testing are getting published (multiple times a day) when PRs have been merged

• PRs to the stable release branch are made with cherry-pick labels on PRs, something like this or this, this is also used for urgent fixes/package pins

• "dangerous" deps like major cosign bumps can be merged when it's proven to not break things in testing (PR still gets created)

• :stable images (stable release branch) are getting published by a small workflow that runs on a schedule, gh workflow run .github/workflows/somebuild.yml --ref somebranch, this is a workaround because we can't run crons on the non-default branch

• in PRs :stable is still getting built, so we know when things are broken and won't get surprised when scheduled builds are failing

• (big) changes (over a long time) can be vetted in :testing/main and can be merged/promoted (via pull bot) without sacrificing security fixes to the stable release branch as main has experimental changes we can't merge into stable release branch yet

This is very similar to how GNOME OS, FSDK, Plasma, Fedora Packages, our Fedora Base image and Flatpak do things. Branches will diverge and we get a "fresh" stable one every 6 months, i.e. f44->f45.
Always having a branch that builds testing and being ahead of the branch that builds the stable images doesn't work (no diverging branches), as regularly force pushing (resetting) the stable branch is not an option we should consider. This seems like the least complex way to do it.

These approaches do not work for us

• The Bazzite way: no renovate triggered daily builds (useless bump PRs), manual merges in both directions (good luck teaching pull bot how to merge in which direction), manual (stable) builds for the most part (we want to avoid manual work!)
• Bluefin LTS: no daily builds published, seems like they are missing out on gh-actions bump PRs and the like on their "lts" branch, which is the equivalent to our stable release branch here

TODO

• Figure out what to do about the package cache, it's only useful when we have manually triggered builds/schedules, relevant for main branch (we currently rely on scheduled builds from main for it's creation)

• document exact approach on how to fix stuff when :stable is on fire

dummy scheduled workflow that only exists to publish cache and nothing else?

[castrojo]

SGTM I'd love to do this in bluefin as well! +1!

[inffy]

Yes this looks like a plan +1

[inffy]

This is how currently the automated backport of the original PR looks

[renner0e]

ublue-os#1647 (comment)