|
1 | 1 | name: Increment Version on Merge
|
| 2 | +run-name: "${{ github.event.pull_request.merged && 'Increment version for' || 'Closing' }} PR #${{ github.event.pull_request.number }}" |
2 | 3 | on:
|
3 | 4 | # https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
|
4 |
| - # - GitHub’s standard pull_request workflow trigger prevents write permissions and secrets |
5 |
| - # access to the target repository from public forks. PRs from a branch in the same repo |
6 |
| - # and forks of internal/private repos are not limited the same way for this trigger. |
7 |
| - # - The pull_request_target trigger allows the workflow to relax some restrictions to a |
8 |
| - # target repository so PRs from forks have write permission to the target repo and have |
9 |
| - # secrets access (which we need in order to push a new tag in this workflow). |
10 |
| - # - For this workflow, the elevated permissions should not be a problem because: |
11 |
| - # - Our im-open repositories do not contain secrets, they are dumb actions |
12 |
| - # - Require approval for all outside collaborators' is set at the org level so someone |
13 |
| - # with Write access has a chance to review code before allowing any workflow runs |
14 |
| - # - This workflow with elevated Write permissions will only run once the code has been |
15 |
| - # reviewed, approved by a CODEOWNER and merged |
| 5 | + # https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token |
| 6 | + # |
| 7 | + # GitHub's standard pull_request workflow trigger prevents write permissions and |
| 8 | + # secrets access when the PR is from a public fork. PRs from branches and forks of |
| 9 | + # internal/private repos are not limited the same way for the pull_request trigger. |
| 10 | + # |
| 11 | + # The pull_request_target trigger (which this workflow is using) relaxes some of those |
| 12 | + # restrictions and allows PRs from public forks to have write permissions through the |
| 13 | + # GH_TOKEN which we need in order to push new tags to the repo through this workflow. |
| 14 | + # |
| 15 | + # For this workflow, the elevated permissions should not be a problem because: |
| 16 | + # • This workflow is only triggered when a PR is closed and the reusable workflow it |
| 17 | + # calls only executes if it has been merged to the default branch. This means the PR |
| 18 | + # has been reviewed and approved by a CODEOWNER and merged by someone with Write |
| 19 | + # access before this workflow with its elevated permissions gets executed. Any code |
| 20 | + # that doesn't meet our standards should be caught before it gets to this point. |
| 21 | + # • The "Require approval for all outside collaborators" setting is set at the org-level. |
| 22 | + # Before a workflow can execute for a PR generated by an outside collaborator, a user |
| 23 | + # with Write access must manually approve the request to execute the workflow run. |
| 24 | + # Prior to doing so they should have had a chance to review any changes in the PR |
16 | 25 | pull_request_target:
|
17 | 26 | types: [closed]
|
18 |
| - paths: |
19 |
| - - 'dist/**' |
20 |
| - - 'src/**' |
21 |
| - - 'action.yml' |
22 |
| - - 'package.json' |
23 |
| - - 'package-lock.json' |
| 27 | + # paths: |
| 28 | + # Do not include specific paths here. reusable-increment-version-on-merge.yml will decide |
| 29 | + # if this action should be incremented and if new tags should be pushed to the repo based |
| 30 | + # on the same criteria used in the build-and-review-pr.yml workflow. |
24 | 31 |
|
25 | 32 | jobs:
|
26 | 33 | increment-version:
|
27 |
| - if: github.event.pull_request.merged == true && github.event.pull_request.base.ref == 'main' |
| 34 | + uses: im-open/.github/.github/workflows/reusable-increment-version-on-merge.yml@v1 |
| 35 | + with: |
| 36 | + default-branch: main |
28 | 37 |
|
29 |
| - runs-on: ubuntu-latest |
| 38 | + # The files that contain source code for the action. Only files that affect the action's execution |
| 39 | + # should be included like action.yml or package.json. Do not include files like README.md or .gitignore. |
| 40 | + # Files do not need to be explicitly provided here if they fall under one of the dirs in dirs-with-code. |
| 41 | + # ** This value must match the same files-with-code argument specified in increment-version-on-merge.yml. |
| 42 | + files-with-code: 'action.yml,package.json,package-lock.json' |
30 | 43 |
|
31 |
| - steps: |
32 |
| - # Generally speaking, when the PR contents are treated as passive data, i.e. not in a |
33 |
| - # position of influence over the build/testing process, it is safe to checkout the code |
34 |
| - # on a pull_request_target. But we need to be extra careful not to trigger any script |
35 |
| - # that may operate on PR controlled contents like in the case of npm install. |
36 |
| - - name: Checkout Repository |
37 |
| - uses: actions/checkout@v3 |
38 |
| - with: |
39 |
| - ref: main |
40 |
| - fetch-depth: 0 |
41 |
| - |
42 |
| - # See https://github.com/im-open/git-version-lite for more details around how to increment |
43 |
| - # major/minor/patch through commit messages |
44 |
| - - name: Increment the version |
45 |
| - uses: im-open/git-version-lite@v2 |
46 |
| - id: version |
47 |
| - with: |
48 |
| - github-token: ${{ secrets.GITHUB_TOKEN }} |
49 |
| - |
50 |
| - - name: Create version tag, create or update major, and minor tags |
51 |
| - run: | |
52 |
| - git config user.name github-actions |
53 |
| - git config user.email github-actions@github.com |
54 |
| - git tag ${{ steps.version.outputs.NEXT_VERSION }} ${{ github.sha }} |
55 |
| - git tag -f ${{ steps.version.outputs.NEXT_MAJOR_VERSION }} ${{ github.sha }} |
56 |
| - git tag -f ${{ steps.version.outputs.NEXT_MINOR_VERSION }} ${{ github.sha }} |
57 |
| - git push origin ${{ steps.version.outputs.NEXT_VERSION }} |
58 |
| - git push origin ${{ steps.version.outputs.NEXT_MAJOR_VERSION }} -f |
59 |
| - git push origin ${{ steps.version.outputs.NEXT_MINOR_VERSION }} -f |
| 44 | + # The directories that contain source code for the action. Only dirs with files that affect the action's |
| 45 | + # execution should be included like src or dist. Do not include dirs like .github or node_modules. |
| 46 | + # ** This value must match the same dirs-with-code argument specified in increment-version-on-merge.yml. |
| 47 | + dirs-with-code: 'src,dist' |
0 commit comments