ci: scope GITHUB_TOKEN to least privilege in release workflow

[Copilot]

The release workflow granted pull-requests: write and contents: write globally — unnecessarily widening the GITHUB_TOKEN blast radius for every job, including ones that never touch releases or PRs.

Changes

• Remove pull-requests: write — nothing in the workflow interacts with PRs
• Deny all permissions at workflow level (permissions: {}) and grant contents: write only to the build job, which is the sole caller of softprops/action-gh-release@v2; the update job now carries zero GITHUB_TOKEN write access
• Replace deprecated ::set-output with $GITHUB_OUTPUT in the update job's version and checksum steps

# Before
permissions:
  pull-requests: write
  contents: write

jobs:
  build: ...
  update: ...

# After
permissions: {}

jobs:
  build:
    permissions:
      contents: write   # only here — only this job publishes release assets
    ...
  update: ...           # relies solely on the GitHub App token

Original prompt

Update the GitHub Actions workflow at .github/workflows/release.yml in repository FlutterGen/flutter_gen to follow a least-privilege permissions model and tighten related workflow hygiene.

Context:

• The current workflow defines top-level permissions:
  • pull-requests: write
  • contents: write
• Based on the workflow behavior, pull-requests: write does not appear to be required.
• contents: write is required for the release asset publishing step using softprops/action-gh-release@v2, but it should be scoped as narrowly as possible to reduce supply-chain risk.
• The workflow also appears to use deprecated ::set-output syntax in the update job.

Requested changes:

1. Rewrite .github/workflows/release.yml to use least privilege.
2. Remove unnecessary workflow-wide permissions.
3. Scope contents: write only to the specific job(s) that need it.
4. Remove pull-requests: write unless it is demonstrably required by the workflow.
5. Preserve the existing release behavior: building artifacts, uploading them to the GitHub Release, collecting checksums, and dispatching the Homebrew tap update.
6. Replace deprecated ::set-output usage with the modern $GITHUB_OUTPUT mechanism.
7. Keep the workflow functional on the repository’s current default branch (main).
8. Make minimal, focused changes; do not refactor unrelated parts of the repository.

Please create a pull request with these changes and include a concise explanation in the PR description of:

• why top-level permissions were reduced,
• why contents: write remains where it does,
• and that pull-requests: write was removed because it was not used by the workflow as written.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Does the new release making and artifacts upload require contents & pull-requesets write permission here? Do they required for this workflow?

Assistant: Short answer: contents: write is required for the release upload step; pull-requests: write does not appear to be required by this workflow as shown.

Why:

• In .github/workflows/release.yml, the workflow sets:

  • pull-requests: write
  • contents: write

• The step that actually creates/updates the GitHub Release and uploads assets is:

- name: Releasing assets
  uses: softprops/action-gh-release@v2
  with:
    files: |
      packages/command/bin/${{ matrix.target }}/fluttergen-${{ matrix.artifact_prefix }}.tar.gz
      packages/command/bin/${{ matrix.target }}/fluttergen-${{ matrix.artifact_prefix }}.sha256
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

That action writes release objects/assets in the repository, which falls under repository contents/releases access, so contents: write is the relevant permission.

What I do not see in this workflow:

• no PR creation
• no PR comment/update
• no label/review/requested-reviewer operations
• no gh CLI or API calls against pull requests

So based on the file you provided, pull-requests: write is unnecessary.

Also note:

• actions/upload-artifact@v4 uploads artifacts to the workflow run artifact store. That does not need pull-requests: write.
• actions/download-artifact@v4.1.8 also does not need pull-requests: write.
• peter-evans/repository-dispatch@v3 sends a dispatch event to another repository using the app token from actions/create-github-app-token@v1; that permission is governed by the GitHub App token’s permissions, not by this workflow’s pull-requests: write on GITHUB_TOKEN.

So the minimal top-level permissions here likely are:

permissions:
  contents: write

If you want, I can also point out a couple of other things in this workflow that look outdated or worth tightening up, like the deprecated set-output usage.

User: You mentioned releases access, does releases has standalone permission entry? Should it be written here?

Assistant: No — there is no standalone releases: permission key in GitHub Actions workflow permissions. For release creation/upload, GitHub documents that contents: write is the permission that allows creating a release. (docs.github.com)

So in your workflow, this is the right form:

permissions:
  contents: write

Not this:

permissions:
  releases: write

Because releases is not one of the workflow GITHUB_TOKEN permission entries documented by GitHub; release management is covered by repository contents write access. GitHub’s REST docs for releases also say creating a release requires Contents repository permission (write) for fine-grained tokens. ([docs.github.com](https://docs.github.com/en/rest/releases/releases?utm_sour...

This pull request was created from Copilot chat.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.37%. Comparing base (c1b02c9) to head (4c6beeb).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #757   +/-   ##
=======================================
  Coverage   97.37%   97.37%           
=======================================
  Files          24       24           
  Lines         989      989           
=======================================
  Hits          963      963           
  Misses         26       26           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

This PR tightens the GitHub Actions release workflow’s GITHUB_TOKEN permissions to a least-privilege model while keeping the release/build and Homebrew tap dispatch behavior intact, and updates workflow outputs to the non-deprecated mechanism.

Changes:

• Removed workflow-wide pull-requests: write and contents: write, replacing with permissions: {} at the workflow level.
• Scoped contents: write only to the build job (the only job that publishes release assets via softprops/action-gh-release@v2).
• Replaced deprecated ::set-output with $GITHUB_OUTPUT in the update job.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.