Repository navigation
Publish the site as an artifact instead of committing it to a branch #198
Description
Activity
@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.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!
Reacted by David ArcosJust 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 😜
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.
editionholds the source andmasterholds the build, written by thegithub-pagesworkflow withpeaceiris/actions-gh-pagesandforce_orphan: true, somasteris 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-artifactandactions/deploy-pages. The build would then never be committed anywhere.What it would change
mastercarries would not be in the repository at all. A clone would fetch only the source.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.
CNAMEexists at the root ofeditionbut is not copied into the build: the deploy action injects it through itscname: pybcn.orginput. Drop that action without replacing it and the built site has noCNAME, which is how a Pages site loses its custom domain. Moving the file tostatic/CNAMEis 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.