Skip to content

write permission is conditionally needed by release-drafter #47

@2bndy5

Description

@2bndy5

The cpp-linter repo has 2 workflows that call into the reusable workflow, .github/workflows/release-drafter.yml:

  1. cpp-linter/cpp-linter/.github/workflows/labeler.yml requires
    permissions:
      contents: read
      pull-requests: write
  2. cpp-linter/cpp-linter/.github/workflows/release-drafter.yml; requires
    permissions:
      contents: write
      pull-requests: read

While the reusable workflow demands write permission regardless of calling context:

# write permission is required to create a github release
contents: write
# write permission is required for autolabeler
# otherwise, read permission is required at least
pull-requests: write

Proposal

The permissions map cannot be dynamically set.

# THIS WILL NOT WORK!
permissions:
  contents: ${{ inputs.mk-labels && 'read' || 'write' }}
  pull-requests: ${{ inputs.mk-draft-release && 'read' || 'write' }}

This means we need 2 separate reusable workflows for each calling context:

  • To auto-label PRs
  • To draft (or update a drafted) release

Because the reusable workflow is just 1 step, I'm inclined to just copy that 1 step into the calling workflows' yml and modify the permissions as needed.

Or use git-cliff + gh-cli

In the cpp-linter-rs repo, I use a script (written in python) to

  1. Bump the version according to inputs.component. In rust this requires altering the Cargo.toml manifest. In python we would only need to calculate the version based on the last tag.
  2. Use git-cliff with the new version number to generate release notes (used in the final step 4). This step also regenerates the entire CHANGELOG.md in repo root.
  3. Use git to push any metadata file changes. The step is not required where setuptools-scm automatically sets the package version based on git describe --tags (or similar).
  4. Use gh-cli (requires a PAT with permissions: {contents: write}) to publish a release, which inherently creates a new tag that triggers build/deploy CI workflows.

Caution

step 4 requires a PAT instead of the generic/default secrets.GITHUB_TOKEN because CI triggers are ignored for events caused by "github-actions[bot]".

This might seem overly complicated, but it provides much better flexibility and does not surrender security to third-party software that we don't control/understand.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions