ci: grant release-please issues permission

[fan-zhang-sv]

Summary

• Add issues: write to the Release Please workflow token permissions.
• Keep the previously merged commit-batch-size: 1 mitigation in place.

Why

The release-please workflow is still failing inside GitHub Actions while executing the first commit-history GraphQL query, even after reducing the commit batch size to 1.

I reproduced the reduced release-please GraphQL query locally with gh api graphql, and it succeeds against master. The remaining difference is the token used in Actions: the workflow uses secrets.GITHUB_TOKEN with only contents: write and pull-requests: write.

Release Please's documented required workflow permissions include issues: write as well:

https://github.com/googleapis/release-please-action?tab=readme-ov-file#workflow-permissions

That permission is relevant because release-please reads PR labels in the failing GraphQL query and may create/update labels on release PRs.

Test plan

• Verified the workflow YAML diff is limited to adding issues: write.
• Existing CI will run on the PR.
• After merge, rerun the Release Please workflow on master.

Made with Cursor

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[github-actions]

Review Summary

PR title: ci: grant release-please issues permission — valid Conventional Commits format, no change needed.

Change: Adds issues: write to the top-level workflow permissions for the release-please workflow.

Assessment: No issues found. This is a minimal, well-justified fix.

• The issues: write permission is documented as required by release-please-action for reading PR labels and managing release labels.
• The permission is correctly placed at the top-level permissions block, which applies to the release-please job (the only job without its own job-level permissions override).
• The publish jobs (publish-account, publish-account-ui) define their own job-level permissions blocks, so they are unaffected by this change and do not inherit the new issues: write scope.
• No security concern: issues: write is a narrow permission scoped to issue/label operations within the repository.