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 configuration change 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 set to read-only.

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 and avoids granting unnecessary access to other jobs.

Additional context

This is part of a batch update across all launchdarkly-sdk-tagged repos whose release-please workflows were missing explicit permissions on their default branch.

Human review checklist

• Adding an explicit job-level permissions block restricts the token to only the listed permissions, revoking any inherited defaults. Confirm contents: write and pull-requests: write are sufficient for the release-please job (the publish-package job already has its own permissions block and is unaffected).

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

---

Note

Low Risk
Low risk CI configuration change that only adjusts GITHUB_TOKEN scopes for the release-please job; main risk is mis-scoped permissions could prevent release PRs/tags from being created.

Overview
Updates .github/workflows/release-please.yml to explicitly grant the release-please job contents: write and pull-requests: write, rather than relying on repository/org default GITHUB_TOKEN permissions.

This ensures the release-please action can create/update release PRs and create releases/tags when default workflow permissions are read-only.

^{Written by Cursor Bugbot for commit 9053809. 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 action

Medium Severity

Adding an explicit job-level permissions block restricts the GITHUB_TOKEN to only the listed permissions, revoking all inherited defaults. The release-please-action v4 documentation (and upstream PR #1108) indicates that issues: write is also required for the action to create labels on issues and pull requests. Without it, the action may fail when attempting label operations.

 

[devin-ai-integration]

The issues: write permission is only needed if release-please is configured to manage labels on issues/PRs. The standard release-please-action v4 usage (creating release PRs and GitHub releases) only requires contents: write and pull-requests: write. The upstream PR #1108 referenced is about a specific label-management feature that isn't used in this workflow configuration.

If label operations are needed in the future, issues: write can be added at that time.