Fix gh-pages deploy: restore java lock URL and build docs on PRs#402
Conversation
📝 WalkthroughWalkthroughThe GitHub Pages workflow now triggers on pull_request events in addition to workflow_dispatch, sets workflow-level permissions to empty, and scopes concurrency by git ref with cancel-in-progress enabled. The gh-pages publish step is now conditional, only running on pushes to main. ChangesPages Workflow Update
Sequence Diagram(s)Not applicable; this PR is a CI workflow configuration change without multi-component application logic. Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates mise.lock to specify a Java platform entry for linux-x64. The review feedback notes that omitting other common platforms (like macOS and Windows) will cause local development installation failures under locked mode, and suggests running mise lock to populate all target platforms.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| [tools.java."platforms.linux-x64"] | ||
| checksum = "sha256:2f2802d57b5fc414f1ddf6648ba12cc9a6454cf67b32ac95407c018f2e6ab0b0" | ||
| url = "https://download.java.net/java/GA/jdk26.0.1/458fda22e4c54d5ba572ab8d2b22eb83/8/GPL/openjdk-26.0.1_linux-x64_bin.tar.gz" |
There was a problem hiding this comment.
While restoring the linux-x64 platform entry fixes the GitHub Actions CI/CD pipeline, mise.lock is still missing entries for other common developer platforms (such as macos-arm64, macos-x64, windows-x64, and linux-arm64) for java.\n\nBecause the enter hook in mise.toml runs mise install --quiet --locked automatically when entering the directory, any developer on macOS or Windows will experience a failure like:\n\nmise ERROR Failed to install core:java@latest: No lockfile URL found for java@26.0.1 on platform macos-arm64 (--locked mode)\n\n\nTo resolve this and support cross-platform local development, please run mise lock locally to automatically populate mise.lock with the URLs and checksums for all target platforms, and commit the updated lockfile.
There was a problem hiding this comment.
(Claude, replying on Greg's behalf.)
Already addressed in a force-push after this review. The lockfile was regenerated with mise lock java, so the current head includes all five platforms (linux-arm64, linux-x64, macos-arm64, macos-x64, windows-x64) plus the [tools.java.options] block. mise install --locked now works for macOS/Windows developers and the enter hook too.
A prior mise.lock regeneration left the core:java entry with only [tools.java.options] and no per-platform url/checksum entries. Under the mise version used in CI, 'mise install --locked' then fails with 'No lockfile URL found for java@26.0.1', which broke the gh-pages deploy (it runs the full locked install). Regenerated with 'mise lock java' to populate the per-platform entries. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Pages workflow only ran on pushes to main, so a broken mise.lock or docs build was not detected until after merge (when the deploy runs the full 'mise install --locked'). Run the build on pull requests too, and gate the gh-pages publish step to pushes on main so PRs validate without deploying. Scope the concurrency group per ref so PR runs do not cancel the main deploy. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
oschwald
force-pushed
the
greg/fix-pages-mise-lock
branch
from
a749d46 to
3b65b5c
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/pages.yml (1)
16-19: 🔒 Security & Privacy | 🔵 Trivial | ⚖️ Poor tradeoffScope
contents: writeto the publish step only.
permissions: contents: writeis declared at the job level, so for same-repo (non-fork) PR runs the GITHUB_TOKEN keeps write access during checkout/mise-install/build-docs even though those steps only need read access — only the gatedgh-pagespush (Line 39) needs write. Fork PRs are forced read-only by GitHub regardless, but same-repo PRs are not. Consider splitting into a build job (contents: read) and a deploy job (contents: write, gated on push to main) to keep PR validation runs least-privileged.♻️ Suggested split
jobs: - build-and-deploy: + build: runs-on: ubuntu-latest permissions: - contents: write + contents: read steps: - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 with: persist-credentials: false ... - name: Build docs ... + + deploy: + needs: build + if: github.event_name == 'push' && github.ref == 'refs/heads/main' + runs-on: ubuntu-latest + permissions: + contents: write + steps: + - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 + ... (rebuild or reuse artifact) + - name: Push rendered site to gh-pages + uses: peaceiris/actions-gh-pages@84c30a85c19949d7eee79c4ff27748b70285e453 # v4.1.0 + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + publish_dir: ./docs/public + publish_branch: gh-pages + keep_files: true + user_name: "github-actions[bot]" + user_email: "41898282+github-actions[bot]`@users.noreply.github.com`"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/pages.yml around lines 16 - 19, Scope the GitHub Actions token permissions more narrowly in build-and-deploy: the current job-level contents: write gives unnecessary write access during checkout, mise-install, and build-docs. Refactor the workflow so the build portion runs with contents: read and only the publish path that pushes to gh-pages uses contents: write, ideally by splitting the existing build-and-deploy job into separate build and deploy jobs with the deploy job gated to the main-branch publish step.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.github/workflows/pages.yml:
- Around line 16-19: Scope the GitHub Actions token permissions more narrowly in
build-and-deploy: the current job-level contents: write gives unnecessary write
access during checkout, mise-install, and build-docs. Refactor the workflow so
the build portion runs with contents: read and only the publish path that pushes
to gh-pages uses contents: write, ideally by splitting the existing
build-and-deploy job into separate build and deploy jobs with the deploy job
gated to the main-branch publish step.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 57f50b22-4738-44d7-a52b-9124de3cb1af
⛔ Files ignored due to path filters (1)
mise.lockis excluded by!**/*.lock
📒 Files selected for processing (1)
.github/workflows/pages.yml
|
(Claude, commenting on Greg's behalf.) Re: CodeRabbit's out-of-diff suggestion to scope Leaving it as a single job for now: the publish step is gated to push-on- (Same rationale applies to the identical change in maxmind/GeoIP2-java#734.) |
2 participants
The "Deploy to GitHub Pages" workflow failed on
mainafter #401 merged (run28465860134).Root cause
The deploy's
Setup misestep runsmise install --locked, which installs the full toolchain — includingjava. Themise.lockupdate in #401 (commit3b9ddb1) replaced java's per-platformurl/checksumentry with a bare[tools.java.options] shorthand_vendor = "openjdk". With no locked URL, the install fails:It wasn't caught on the PR because
pages.ymlonly triggered onpush: [main], and the PR job that uses mise (links.yml) installs lychee-only (install: false) — so no PR ran the full locked install.Changes (two commits)
mise.lock— recoversmise install --lockedso the Pages deploy works again. (Restored byte-identical to the pre-Clarify Windows memory-map file locking and fix Javadoc issues #401 lockfile entry; the hugo/lychee/maven bumps from Clarify Windows memory-map file locking and fix Javadoc issues #401 are untouched.)pages.ymlnow also runs onpull_request, executingSetup mise(fullmise install --locked) +Build docs, with the gh-pages publish step gated to pushes onmain. A broken lockfile or docs build now fails the PR before merge. Concurrency group is scoped per-ref so PR runs don't cancel the main deploy.Companion to maxmind/GeoIP2-java#734, which had the same failure.
Note: commits are unsigned because the local 1Password signing agent was unavailable at authoring time.
🤖 Generated with Claude Code
Summary by CodeRabbit