ci: set explicit permissions on workflows missing them

[harshil-mistry]

Summary

Adds an explicit permissions: block to the six workflows that didn't have one, scoped to what each actually needs.

Details

Without a permissions: block a workflow's GITHUB_TOKEN inherits the repository/org default rather than being scoped to its job. The other 41 workflows here already declare one, and the repo is otherwise careful about this (actions pinned to full SHAs with # ratchet: comments, persist-credentials: false on checkouts), so these six looked like oversights.

I read each workflow before choosing a scope rather than blanket-applying contents: read:

Workflow	Set to	Why
deflake.yml	contents: 'read'	checkout, npm ci, build, docker
links.yml	contents: 'read'	checkout + lychee link check
tools-python-ci.yml	contents: 'read'	checkout + setup-python + tests
trigger_e2e.yml	contents: 'read'	shell steps + upload-artifact
issue-opened-labeler.yml	issues: 'write'	needs write; see below
docs-rebuild.yml	{}	never touches the GitHub API

Two that aren't just contents: read:

issue-opened-labeler.yml needs issues: write. It prefers a GitHub App token but falls back to secrets.GITHUB_TOKEN when APP_ID is unset (github-token: '${{ steps.generate_token.outputs.token || secrets.GITHUB_TOKEN }}'), then calls issues.get and issues.addLabels. Pinning it to read would look tidier but would break labeling on that fallback path.

docs-rebuild.yml gets permissions: {}. Its only step curls secrets.DOCS_REBUILD_URL — no checkout, no API calls — so it needs no token scopes at all.

This is hardening rather than a bug fix: if the repo default is already read-only, nothing changes at runtime. Formatting follows the existing convention in this repo (quoted scalar values).

Related Issues

Fixes #29014

How to Validate

1. for f in .github/workflows/*.yml; do grep -q "permissions:" "$f" || echo "$f"; done — lists the six before the change, nothing after.
2. Parsed all six with a YAML parser after editing to confirm they still load and that permissions resolves as intended ({'contents': 'read'}, {'issues': 'write'}, {}) with each file's job list unchanged.
3. Traced each workflow's steps to justify the scope — in particular confirming the labeler's GITHUB_TOKEN fallback path and its issues.addLabels call, and that docs-rebuild.yml makes no API calls.

The real confirmation is that these workflows behave identically after merge; the labeler is the one to watch, since it's the only one needing write.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed) — n/a
• Added/updated tests (if needed) — n/a, workflow config
• Noted breaking changes (if any) — none intended; see the labeler note above
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux

Platform matrix left unchecked deliberately — this changes GitHub Actions config only, with no code path to exercise per platform, and I can't run these workflows from a fork. npm run preflight not run for the same reason.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[github-actions]

📊 PR Size: size/S

• Lines changed: 18
• Additions: +18
• Deletions: -0
• Files changed: 6

[harshil-mistry]

@googlebot I signed it!

[harshil-mistry]

Pushed a follow-up commit to fix the failing zizmor-output check.

zizmor flagged issue-opened-labeler.yml:23 — "dangerous use of GitHub App tokens: app token inherits blanket installation permissions". To be clear about cause: that finding is pre-existing, not something this PR introduced. The create-github-app-token step is byte-identical to main; my permissions: block shifted it from line 20 to line 23, and since zizmor only audits changed files, modifying the file is what surfaced it.

I fixed it rather than leaving the check red, since it's the same least-privilege concern this PR is about: the step now passes permission-issues: 'write' to create-github-app-token, so the app token is scoped to what the workflow actually uses (issues.get and issues.addLabels) instead of inheriting every permission the installation has.

That leaves the workflow scoped at both levels — permissions: issues: write for the fallback GITHUB_TOKEN path, and permission-issues: write for the app-token path.

Happy to split this into its own PR if you'd rather keep the two separate.