You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# 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.
In the cpp-linter-rs repo, I use a script (written in python) to
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.
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.
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).
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.
The cpp-linter repo has 2 workflows that call into the reusable workflow,
.github/workflows/release-drafter.yml:While the reusable workflow demands write permission regardless of calling context:
.github/.github/workflows/release-drafter.yml
Lines 15 to 19 in 86b6518
Proposal
The
permissionsmap cannot be dynamically set.This means we need 2 separate reusable workflows for each calling context:
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
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.gitto push any metadata file changes. The step is not required wheresetuptools-scmautomatically sets the package version based ongit describe --tags(or similar).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_TOKENbecause 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.