feat!: only deploy the branch named "live", to simplify development

[Arcitec]

Rewires the GitHub workflow a bit, to make it much easier to create custom images based on startingpoint. With these changes, the following technique becomes possible for our downstream users:

• Users fork the ublue-os/startingpoint repo.
• They turn it away from "template" mode into regular repo mode.
• They link the template branch to upstream for easy syncing (just a simple "set upstream" git command locally). In fact, they can do that syncing effortlessly via the GitHub web UI with one click since that's doable by default (there's a "Sync fork" button whenever users view the "primary upstream" branch on their forks).
• They create a live branch and perform their own edits there.
• They periodically sync the upstream template and then rebase their own live onto template to get the latest template improvements.
• This technique would be impossible without these changes, because the template branch would constantly deploy itself and overwrite your real GHCR contents. And in general, there would be a mess whenever you have multiple development/test branches, which would all be built and deployed to GHCR and collide with each other. This fixes all of that.

Before v1.0, we should also rename the main branch in this repo to template instead (what I used in the list above), and mark template as the primary branch.

That way, all downstream repos will only have two clear and easy branches to deal with:

• template = That's the untouched upstream, which they periodically sync to get the latest improvements.
• live = That's their actual deployment branch, which they periodically rebase onto template to get the freshest changes.
• Other branches = They'll be built, but won't be deployed (published), which means that development branches don't interfere with the GHCR container repo stability.

Simple. Easy. Enjoyable. :)

[Arcitec]

@EinoHR One moment, I'll change the branch name to publish instead to be even clearer for users.

Edit: Alright, this is ready for review.

[Arcitec]

Also note that renaming a branch automatically redirects web URLs to the new name. So the old main will be linked to template automatically.

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch

[xynydev]

Before v1.0, we should also rename the main branch in this repo to template instead, and mark template as the primary branch.

So does this mean that we should do it right after this PR is merged? Your wording about main/template is kind of vague. I guess it wouldn't matter either way.

Re: only build the customized branch
I guess this would mean that the repo in the uBlue org would never be built, meaning we'd never catch build errors and have to fork / update a branch constantly to test the changes.

I'm having trouble seeing what the benefit of including the template's code in your own branch is, when you can already rebase on top of remote branches locally by having multiple remotes (ie. how create-ublue-image sets it up, upstream and origin branches where you can fetch, merge, rebase on top of, etc. on upstream).

On a tangent... The official docs IIRC currently recommend forking the repo to get that GUI dialog to sync your fork, but that's not how I do it because you can only have one fork per repo, and honestly syncing via CLI is just as easy but more powerful (when you've got the commands written down...).

Edit:

build: The initial one, but then I thought "this makes no sense... every branch is built by the workflow, not just this one". The only unique thing about the special branch is that it will be the only one that's deployed to GHCR. Which brought m to...

So all branches get still built by the new workflow (even though only the custom one is mentioned in the build.yml in the PR and push sections?

[Arcitec]

So does this mean that we should do it right after this PR is merged? Your wording about main/template is kind of vague. I guess it wouldn't matter either way.

The rename would be a good idea after merge, to get it over with before even more people use this template repo.

I'm having trouble seeing what the benefit of including the template's code in your own branch is, when you can already rebase on top of remote branches locally by having multiple remotes.

By including the template in your own branch, we make it more accessible to everyone since GitHub has a super easy GUI for syncing the template branch. Not everyone's gonna be adept at setting up remote branches locally.

So all branches get still built by the new workflow (even though only the custom one is mentioned in the build.yml in the PR and push sections?

Yes every branch and pull request gets built when they change. The result is simply never pushed to GHCR unless it's the live branch.

We'll still be able to work on startingpoint:template and seeing GitHub's build test results for all changes to it.

This means that we retain the ability to develop in other branches and ensure things build, without destroying GHCR's public registry. :)

[xynydev]

Alright, thanks for keeping me informed. Since this makes things a bit more clear (and easier for less-wizardy git users), but doesn't seem to hurt anything, I guess it's good to go.

Maybe change the branch name then and we good?

[Arcitec]

@EinoHR Regarding the benefit of having that "Sync fork" button: That was added to GitHub precisely because people had so much trouble keeping their forks in sync. There used to be literal WEBSITES made by people on github.io where you went and plugged in your GitHub credentials to have that website do the fork syncing for you. There were tons of questions about fork syncing on Stack Overflow. That's how bad people are at this!

Here's the button we get by having the proposed branch layout:

❤️

[xynydev]

This branch is 1 commit behind startingpoint:template.

Is this on customrepo:template or customrepo:live? Does one need to both sync their template and manually rebase on top of it / do a merge or is that handled automatically?

[Arcitec]

Is this on customrepo:template or customrepo:live? Does one need to both sync their template and manually rebase on top of it / do a merge or is that handled automatically?

It's on template. So they'll click that button in the web GUI (or git pull --ff-only --all on local git), and then voila their own fork has both their own live and the upstream's latest template in the repo.

After that they can do whatever workflow they prefer. I'd always recommend people do an interactive rebase of their live onto template to keep their personal changes / history clean and easy to understand. :)

[xynydev]

Seems that the workflows aren't running. I can't even open the logs. Are you sure the build.yml changes don't disable builds on PRs and pushes for branches other than live?

[Arcitec]

@EinoHR Oh yeah just in case you missed the link, here's the docs about renaming main to template. It will automatically set up a redirect for us for old URLs. :)

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch

Edit for anyone who might read this thread in the future:

We found out that workflows in pull requests use the workflow of the primary branch of the forked repo, not the upstream, which is why Eino saw that the actions weren't running. We have fixed all issues with pull request builds in the final version of these commits. The new GitHub action workflow now runs for every pull request. More details are in the code comments of the commits.