[AndreasIgel]

Upstream counterpart of fork PR AndreasIgel#12. Head branch: AndreasIgel/simple-builders-fork:feature/165-narrow-pr-write-scope → base java-helpers/simple-builders:main.

Summary

Applies least-privilege to the build job's GITHUB_TOKEN.

Fixes #165

The build job granted pull-requests: write, but no step uses the workflow token to write to PRs — SonarCloud and Codecov PR decoration/comments are done by their GitHub Apps with their own tokens. Removed the scope:

permissions:
  contents: read
  checks: write        # pull-requests: write removed

This limits blast radius if a build step or third-party action is compromised. pull-requests: write remains where it is genuinely needed (the dependency-review workflow's PR summary comment).

Validation

• actionlint passes.
• Workflow-only change; Maven build unaffected.

Red build/dependency-review checks on the fork are the missing SONAR_TOKEN/CODECOV_TOKEN and disabled Dependency graph (unrelated to permission scope).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[AndreasIgel]

Please check the description of the commit and the pullrequest, which introduced this permission. I guess this has been done on purpose because something did not work without!

[AndreasIgel]

I checked the origin of pull-requests: write. It was added in #27 ("Update maven.yml", no description) when the job only ran mvn package — before the SonarCloud (#58) and Codecov (#71) integrations existed, so it cannot have been added for decoration.

On current main no step passes GITHUB_TOKEN to the scanner and nothing uses github.token/gh pr to write to PRs. SonarCloud/Codecov PR decoration is done server-side using tokens configured in their project settings (not the workflow GITHUB_TOKEN). So the permission is genuinely unused and safe to drop. I reworded the code comment accordingly (removing the inaccurate "GitHub Apps" wording).

[AndreasIgel]

Comment for a removed permission should be removed. There should be only a comment about the still demanded permissions here and there background.

[AndreasIgel]

Addressed. The code comment now only documents the retained permissions and their rationale (contents: read for checkout/build, checks: write for test/analysis check output), with no explanation of the removed pull-requests: write. The reasoning for the removal lives in this PR description, not in the workflow file. Pushed to feature/165-narrow-pr-write-scope.