chore: add explicit permissions to release-please workflow

[kinyoklion]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

No test changes needed — this is a CI workflow permissions fix only.

Related issues

N/A — identified during an audit of all non-archived launchdarkly-sdk-tagged repositories for missing release-please workflow permissions.

Describe the solution you've provided

Adds explicit contents: write and pull-requests: write permissions to the release-please job. These are required for the release-please action to:

• Create and update release PRs (pull-requests: write)
• Create GitHub releases and push tags (contents: write)

Without explicit permissions, the job relies on the repository/org default GITHUB_TOKEN permissions, which may be insufficient if defaults are tightened to read-only.

Downstream release jobs (release-server-sdk, release-server-sdk-otel, etc.) already have their own explicit permissions blocks and are unaffected.

Describe alternatives you've considered

Setting permissions at the workflow level (top-level permissions: key) was considered, but job-level scoping follows the principle of least privilege.

Additional context

This is part of a batch fix across all launchdarkly-sdk-tagged repositories whose release-please workflows were missing explicit permissions.

Human review checklist

• Adding an explicit job-level permissions block restricts the token to only the listed permissions (plus metadata: read). Confirm the release-please-action step does not require any additional permissions (e.g., id-token: write) in this repo's configuration.

Link to Devin session: https://app.devin.ai/sessions/a83b6e4f4fa14b96b859cfb50755a2c1
Requested by: @kinyoklion

---

Note

Low Risk
Low risk CI-only change that adjusts GitHub Actions token permissions; main impact is enabling/disabling release automation if mis-scoped.

Overview
Release automation hardening: the release-please job now explicitly requests contents: write and pull-requests: write permissions in .github/workflows/release-please.yml.

This removes reliance on repository/org default GITHUB_TOKEN permissions and ensures the release-please action can create/update release PRs and create tags/releases.

^{Written by Cursor Bugbot for commit 9c53991. This will update automatically on new commits. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[cursor]

Missing issues: write permission for release-please label creation

High Severity

The new explicit permissions block is missing issues: write, which release-please-action v4.4.0 requires to create labels on pull requests when using secrets.GITHUB_TOKEN. Before this change, the job inherited default token permissions (which likely included issues: write). Adding an explicit permissions block restricts the token to only the listed permissions plus metadata: read, so issues: write is now effectively revoked. This can cause the action to fail with "You do not have permission to create labels on this repository," and without proper labels, subsequent release triggers may also break.

 

[kinyoklion]

Irrelevant when the label has already been created.