Increment Version for PR #18 #12
Workflow file for this run
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| name: Increment Version on Merge | |
| run-name: 'Increment Version for PR #${{ github.event.pull_request.number }}' | |
| on: | |
| # https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ | |
| # https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token | |
| # | |
| # GitHub's standard pull_request workflow trigger prevents write permissions and | |
| # secrets access when the PR is from a public fork. PRs from branches and forks of | |
| # internal/private repos are not limited the same way for the pull_request trigger. | |
| # | |
| # The pull_request_target trigger (which this workflow is using) relaxes some of those | |
| # restrictions and allows PRs from public forks to have write permissions through the | |
| # GH_TOKEN which we need in order to push new tags to the repo through this workflow. | |
| # | |
| # For this workflow, the elevated permissions should not be a problem because: | |
| # • This workflow is only triggered when a PR is closed and the reusable workflow it | |
| # calls only executes if it has been merged to the default branch. This means the PR | |
| # has been reviewed and approved by a CODEOWNER and merged by someone with Write | |
| # access before this workflow with its elevated permissions gets executed. Any code | |
| # that doesn't meet our standards should be caught before it gets to this point. | |
| # • The "Require approval for all outside collaborators" setting is set at the org-level. | |
| # Before a workflow can execute for a PR generated by an outside collaborator, a user | |
| # with Write access must manually approve the request to execute the workflow run. | |
| # Prior to doing so they should have had a chance to review any changes in the PR | |
| pull_request_target: | |
| types: [closed] | |
| # paths: | |
| # Do not include specific paths here. reusable-increment-version-on-merge.yml will decide | |
| # if this action should be incremented and if new tags should be pushed to the repo based | |
| # on the same criteria used in the build-and-review-pr.yml workflow. | |
| jobs: | |
| increment-version: | |
| uses: im-open/.github/.github/workflows/reusable-increment-version-on-merge.yml@v1 | |
| with: | |
| default-branch: main | |
| # The files that contain source code for the action. Only files that affect the action's execution | |
| # should be included like action.yml or package.json. Do not include files like README.md or .gitignore. | |
| # Files do not need to be explicitly provided here if they fall under one of the dirs in dirs-with-code. | |
| # ** This value must match the same files-with-code argument specified in build-and-review-pr.yml. | |
| files-with-code: 'action.yml,package-lock.json,package.json' | |
| # The directories that contain source code for the action. Only dirs with files that affect the action's | |
| # execution should be included like src or dist. Do not include dirs like .github or node_modules. | |
| # ** This value must match the same dirs-with-code argument specified in build-and-review-pr.yml. | |
| dirs-with-code: 'src,.build-linux,.build-win' |