Publish with the git-pages action instead of pushing a pages branch #2
Loading…
Reference in a new issue
No description provided.
Delete branch "t3/use-git-pages-action-in-deploy"
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?
Why
The deploy workflow successfully built the site and pushed it to the
pagesbranch, but that never reached the live site:
star/pagesnor thestarorg has awebhook, and the workflow itself never called git-pages, so no publish
request was ever made (
pages: POST/PUTis absent from the git-pages log).star.pages.jingus.dev/is configured withindex-repo-branch = "main",so a push to
pagesis rejected by the ref allowlist. Publishingmainwould upload the Astro sources instead of the built site, and targeting
/pages/would move the site off/.What
Replace the "push the built output to the
pagesbranch" step with the samearchive-upload pattern
jingus/pagesalready uses successfully:_site/vianix build --no-link --print-out-paths .#siteactions/git-pages@v2.2.0tohttps://star.pages.jingus.dev/(
server: pages.jingus.devto bootstrap over the apex cert, automaticforgejo.token,source: _site/)The
contents: writepermission is dropped because the workflow no longerpushes to the repository. The action reference resolves through
data.forgejo.org/actions/git-pages, as it does injingus/pages.star.pages.jingus.dev/maps tostar/pages, so the automatic token issufficient for forge-auth.
Also update the README's deploy/layout notes so they no longer describe the
pagesbranch convention.Verification
git-pages-cli --upload-dir ... --dry-runagainst the live server returnsdry-run ok(server-side forge-auth path).http://star.pages.jingus.dev/confirmed the root siteaccepts a
mainref and that the oldpagesref push is rejected by theallowlist.
After merge
The next push to
main(or a manualworkflow_dispatch) will perform thefirst real git-pages upload, creating the manifest for
star.pages.jingus.dev.