Migrate Pages to Actions deploy and fix changelog race#251
Merged
Conversation
Drop the push-tags trigger in favor of an explicit gh workflow run dispatch from release-tag.yml after the GitHub Release is created — the release-published event would not fire across the GITHUB_TOKEN boundary, so a chained workflow_dispatch is the reliable path. Other adjustments: per-job permissions (build = contents:read, deploy = pages:write+id-token:write), JEKYLL_GITHUB_TOKEN for jekyll-github-metadata, sanity check on the Jekyll output, fastlane Bundler wiring verification step, action-gh-release v2.5.0 -> v3.0.0, drop dead AGP build-cache step, drop redundant Gemfile excludes from _config.yml, add Jekyll output paths to .gitignore.
4 tasks
gh workflow run requires actions:write on the GITHUB_TOKEN; without it the chained dispatch from release-tag.yml would 403. Also gate the Pages deploy job on github.ref == 'refs/heads/main' so a manual workflow_dispatch from a feature branch builds for validation but doesn't ship.
Adds pull_request trigger so docs-affecting PRs catch Jekyll build breakage before merge. Deploy job is structurally gated on github.ref == 'refs/heads/main', so PR builds (whose ref is refs/pull/N/merge) cannot ship.
Member
Author
|
Heads-up from comparing trigger architectures across the parallel sister-repo PRs (capod#556 is the equivalent on the AirPods repo). The new So whether the chain succeeds depends on this repo's default workflow-token permissions:
Easy fix: add release-github:
permissions:
contents: write
actions: write |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
The website's changelog page on
octi.darken.euwill stay in sync with new releases. Until now the rendered changelog could fall behind the actual GitHub Releases, sometimes for weeks, until an unrelated commit happened to land onmain.Technical Context
main. Tag pushes do not land onmaindirectly — they triggerrelease-tag.yml, which then publishes the GitHub Release minutes later. Jekyll'ssite.github.releases(viajekyll-github-metadata) therefore captured stale data, and the next site rebuild only happened on the next unrelatedmainpush.pages.yml. All Pages actions are pinned by SHA and Node-24 native (configure-pages@v6,jekyll-build-pages@v1.0.13,upload-pages-artifact@v5,deploy-pages@v5).JEKYLL_GITHUB_TOKENis set on the build step sojekyll-github-metadatais authenticated. The build job runs withcontents: readonly;pages: writeandid-token: writeare scoped to the deploy job. A sanity-check step asserts_site/index.htmland_site/CNAMEexist, catching silent Jekyll-output failures (over-aggressive_config.ymlexcludes, dropped CNAME).workflow_dispatch. Afterrelease-githubfinishes creating the GitHub Release, it callsgh workflow run pages.yml --ref mainto chain the rebuild.workflow_dispatchis one of the documented exceptions wheresecrets.GITHUB_TOKEN-emitted events do create new workflow runs;release: publishedis not in that exception list, so it would not fire from a release created via the GitHub Token. This is why we did not adopt therelease: publishedtrigger pattern used by some sister-project PRs.Gemfile/Gemfile.lockintofastlane/.actions/jekyll-build-pagesreadsSOURCE/Gemfileand the root file only declaredgem "fastlane", which conflicted withgithub-pages. Therelease-gplayjob now pointsBUNDLE_GEMFILEandruby/setup-ruby'sworking-directoryat the moved location;bundle exec fastlane …keeps running from the repo root, so lane discovery is unchanged. Abundle exec fastlane --versionstep right aftersetup-rubyexercises the wiring on every release — the lane bodies are gated behind!dry_run, so this is the only way to e2e-test the relocation short of a real beta tag.softprops/action-gh-releasev2.5.0 → v3.0.0 (Node-24 bump), drop the dead~/.android/build-cachecache step (AGP 7+ doesn't write to that path), drop redundantGemfile/Gemfile.lockexcludes from_config.yml, add_site/,.jekyll-cache/,vendor/bundle/to.gitignore.Review guidance
gh api -X PUT repos/d4rken-org/octi/pages -f build_type=workflow. Custom domainocti.darken.euand HTTPS enforcement are preserved across the flip.release-gplayGemfile relocation can't be exercised viaworkflow_dispatch dry_run=true(the lane steps are gated behind!dry_run); the newVerify fastlane Bundler wiringstep covers it on every release.workflow_dispatchpages.ymlonce to rebuild with the latest releases without waiting for the next tag.