Repository navigation
Publish the site as an artifact instead of committing it to a branch #198
Description
Suggested by @ber2 in the review of #193, which asked whether this repository is mixing two artifacts: the code that builds the site, and the built site.
It is, and they are separated as two branches rather than two repositories. edition holds the source and master holds the build, written by the github-pages workflow with peaceiris/actions-gh-pages and force_orphan: true, so master is a single commit replaced on each deploy rather than a history that grows. GitHub Pages serves from that branch.
That is not expensive, but it is avoidable. GitHub Pages can take the build as a workflow artifact instead, with actions/upload-pages-artifact and actions/deploy-pages. The build would then never be committed anywhere.
What it would change
- The 691 blobs and about 72 MB of build output that
mastercarries would not be in the repository at all. A clone would fetch only the source. - Nothing would write to a branch on our behalf. The workflow currently force-pushes an orphan commit on every merge.
- The deployment becomes a GitHub environment, with its own history and its own protection rules, instead of a branch write.
mastercould be deleted.
What it needs, and the one trap
The repository setting has to move from "Deploy from a branch" to "GitHub Actions", which is manual and is the step that makes the change visible.
The custom domain is the trap. CNAME exists at the root of edition but is not copied into the build: the deploy action injects it through its cname: pybcn.org input. Drop that action without replacing it and the built site has no CNAME, which is how a Pages site loses its custom domain. Moving the file to static/CNAME is the fix, and it has to be in the same change rather than after it.
Worth doing, not urgent, and best done when someone can watch the deploy.
Activity
DZPM commentedon Oct 5, 2026
@ber2 this is your suggestion written up, so the call is yours: whether it is worth doing at all, and when. Reassigning it to you.
My advice: this makes sense to me in the future, but maybe not now. Nothing is broken today, the branch is a single replaced commit rather than a growing history, and the one trap in it, the
CNAME, is the kind of thing that costs an outage if it is done in a hurry. Better when someone has an afternoon and can watch the deploy.ber2 commentedon Oct 5, 2026
I was just asking out of curiosity; there is no need to separate the artifacts into two repos, as the instructions for collaborators are now clear (ie: checkout only the relevant branch) and the github action doing the build points to the master branch, which is fine.
I do not think we need to implement any change in this respect, so it's fine to close the issue. Thanks for documenting the discussion!
DZPM commentedon Oct 5, 2026
Just FYI, my new blog build with just 1 branch, so for me it feels more natural.
I'll change again the issue if we migrate to Pelican 😜