General: Migrate Pages to Actions deploy and refresh Node-20 actions#556
Merged
Conversation
Replaces the auto pages-build-deployment (which still uses Node-20 actions/checkout@v4 and actions/upload-artifact@v4) with a custom workflow using configure-pages@v6, jekyll-build-pages@v1.0.13, upload-pages-artifact@v5, deploy-pages@v5. Triggered by release publication so the changelog Liquid template (which reads site.github.releases) only rebuilds when a release actually exists. workflow_dispatch is kept for manual rebuilds when debugging Pages content.
The root Gemfile only ever declared the fastlane gem and lived next to fastlane configuration anyway. Moving it under fastlane/ matches that ownership and keeps the repo root cleaner. release-gplay job now sets BUNDLE_GEMFILE=fastlane/Gemfile and runs ruby/setup-ruby with working-directory=fastlane so bundler-cache resolves the moved Gemfile. fastlane lanes still run from the repo root.
…nements release: published events triggered by secrets.GITHUB_TOKEN do not start new workflow runs (only workflow_dispatch and repository_dispatch are exceptions). The Pages workflow's release: published trigger would never have fired in production since release-tag.yml's softprops/action-gh-release uses GITHUB_TOKEN to publish. Fix: drop the release: published trigger and have release-tag.yml's release-github job explicitly run gh workflow run pages.yml --ref main after the release is created. release-github gains actions: write to authorize the dispatch. Also adopts refinements from sibling org PRs (permission-pilot#356, bluemusic#220): - Top-level permissions reduced to contents: read; pages: write and id-token: write moved to the deploy job only (least privilege) - JEKYLL_GITHUB_TOKEN on the build step so jekyll-github-metadata authenticates when fetching site.github.releases - Sanity-check step (test -f _site/index.html && _site/CNAME) fails fast if Jekyll produced nothing - Explicit upload-pages-artifact path: ./_site matches the build's destination - Verify fastlane Bundler wiring step (bundle exec fastlane --version) lets workflow_dispatch dry_run=true exercise the relocated Gemfile before the next real release
After moving Gemfile/Gemfile.lock to fastlane/, the - Gemfile / - Gemfile.lock entries in _config.yml's exclude list are no-ops; the parent fastlane exclude already covers everything inside. .gitignore picks up _site/, .jekyll-cache/, vendor/bundle/ so local Jekyll runs don't leave tracked artifacts.
Member
Author
|
Cross-flagging from a parallel migration in octi#251 — the Per GitHub's docs on triggering a workflow from a workflow:
The two ways out:
Easy to verify on a draft tag: tag a |
Adds push: [main] alongside workflow_dispatch so edits to README.md, _config.yml, _layouts, or the CHANGELOG.md template publish without a manual dispatch. The chain step in release-tag.yml still runs after release publish to guarantee the new release is in site.github.releases by the time Pages rebuilds — concurrency: cancel-in-progress: false serialises the two runs. Adds an if: github.ref == 'refs/heads/main' guard on the deploy job so workflow_dispatch from a non-main branch builds for verification but doesn't deploy.
app-common module was merged into app/ in be8f491; the exclude has been a no-op since.
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
No user-facing behavior change.
CI/CD maintenance to clear Node 20 deprecation warnings before GitHub forces Node 24 on 2026-06-02 and removes Node 20 entirely on 2026-09-16 (changelog). Eight focused commits:
action-gh-releasev2.5.0 → v3.0.0 inrelease-tag.yml. v3 is the only line that runs on Node 24; inputs we use (prerelease,tag_name,name,generate_release_notes,files) are unchanged.~/.android/build-cachecache step incommon-setup. The path is rarely created by lint / unit-test / assemble-debug jobs, so the cache action emittedPath Validation Error: Path(s) specified in the action for caching do(es) not existon every run without saving anything useful..github/workflows/pages.yml) replacing GitHub's autopages-build-deployment(which still pinsactions/checkout@v4+actions/upload-artifact@v4on Node 20). Usesconfigure-pages@v6,jekyll-build-pages@v1.0.13,upload-pages-artifact@v5,deploy-pages@v5— all on Node 24.Gemfile/Gemfile.lock→fastlane/. Fastlane was the only consumer;release-gplaynow setsBUNDLE_GEMFILE=fastlane/Gemfileand runsruby/setup-rubywithworking-directory: fastlane; lanes still run from the repo root.release-tag.yml+ sibling-PR refinements: per-job least-privilege permissions,JEKYLL_GITHUB_TOKENon the Jekyll build step, Jekyll output sanity check, explicitupload-pages-artifactpath, fastlane Bundler wiring sanity step.release-githubgainsactions: writeso the chain dispatch is allowed regardless of repo default workflow-token permissions._config.ymland ignore Jekyll artifacts in.gitignore(_site/,.jekyll-cache/,vendor/bundle/).push: [main](not just the chain). Lets edits to README.md /_config.yml/_layouts// the CHANGELOG.md template publish without manual dispatch. The chain remains so the post-release rebuild captures the just-published release insite.github.releases.concurrency: group: pages, cancel-in-progress: falseserialises the two runs around a release. Adds anif: github.ref == 'refs/heads/main'deploy guard so aworkflow_dispatchfrom a non-main branch builds for verification but does not deploy.app-commonexclude in_config.yml(the module was merged intoapp/inbe8f4919).Technical Context
gh workflow runand notrelease: published: events triggered bysecrets.GITHUB_TOKEN(whichsoftprops/action-gh-releaseuses) do not start new workflow runs — onlyworkflow_dispatchandrepository_dispatchare exceptions (docs). Arelease: publishedtrigger would never fire in production.workflow_runwas rejected because arelease-gplayfailure marks the whole runfailureand would skip the rebuild even when the GitHub Release succeeded.pages-build-deploymentrebuilt as soon as the release commit landed onmain, but the GitHub Release itself only appeared minutes later (after the APK build finishes inrelease-tag.yml).site.github.releasestherefore captured a snapshot without the new release. capod's v5.1.1-rc0 release was missed by 1h 41m and only got fixed by an unrelated follow-up push tomain. The new chain rebuilds Pages after the release is published, so the changelog page is always current.actions: writeonrelease-github: required forgh workflow runagainst this repo. Without it, the dispatch returns 403 if repo Settings → Actions → Workflow permissions is on the GitHub default ("Read repository contents and packages permissions").dorny/test-reporterNode 24 bump (sibling sdmaid-se PR includes it; capod has notest-reports.yml).Review checklist
gh api -X PUT repos/d4rken-org/capod/pages -f build_type=workflow. Verifycname=capod.darken.euandhttps_enforced=truesurvive the flip.Deploy GitHub Pagesrun fires on the merge commit (because of the newpush: [main]trigger) andhttps://capod.darken.eu/changelogstill shows v5.1.1-rc0 as latest.Tagged releasesviaworkflow_dispatchwithdry_run=true. The new "Verify fastlane Bundler wiring" step (bundle exec fastlane --version) should pass — it exercises the relocated Gemfile end-to-end without uploading anything.v*tag: confirm the "Trigger GitHub Pages deployment" step ran inrelease-github, that a chainedDeploy GitHub Pagesrun appears immediately after, and that the changelog page picks up the new release.