-
Notifications
You must be signed in to change notification settings - Fork 0
Description
The cpp-linter repo has 2 workflows that call into the reusable workflow, .github/workflows/release-drafter.yml:
- cpp-linter/cpp-linter/.github/workflows/labeler.yml requires
permissions: contents: read pull-requests: write
- 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:
.github/.github/workflows/release-drafter.yml
Lines 15 to 19 in 86b6518
| # 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
- 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
gitto push any metadata file changes. The step is not required wheresetuptools-scmautomatically sets the package version based ongit 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.