Merge pull request #33 from im-open/build-refactor

ARCH-1916 - Workflow Refactor

.github/workflows/build-and-review-pr.yml

@@ -0,0 +1,62 @@
+name: Build and Review PR
+run-name: 'Build and Review PR #${{ github.event.pull_request.number }}'
+
+on:
+  # https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
+  #
+  # This workflow uses the pull_request trigger which prevents write permissions on the
+  # GH_TOKEN and secrets access from public forks.  This should remain as a pull_request
+  # trigger to minimize the access public forks have in the repository.  The reduced
+  # permissions are adequate but do mean that re-compiles and readme changes will have to be
+  # made manually by the PR author.  These auto-updates could be done by this workflow
+  # for branches but in order to re-trigger a PR build (which is needed for status checks),
+  # we would make the commits with a different user and their PAT.  To minimize exposure
+  # and complication we will request those changes be manually made by the PR author.
+  pull_request:
+    types: [opened, synchronize, reopened]
+  # paths:
+  #   Do not include specific paths here.  We always want this build to run and produce a
+  #   status check which are branch protection rules can use.  If this is skipped because of
+  #   path filtering, a status check will not be created and we won't be able to merge the PR
+  #   without disabling that requirement.  If we have a status check that is always produced,
+  #   we can also use that to require all branches be up to date before they are merged.
+
+jobs:
+  build-and-review-pr:
+    # This reusable workflow will check to see if an action's source code has changed based on
+    # whether the PR includes files that match the files-with-code arg or are in one of the
+    # dirs-with-code directories.  If there are source code changes, this reusable workflow
+    # will then run the action's build (if one was provided) and update the README.md with the
+    # the latest version of the action.  If those two steps result in any changes that need to
+    # be committed, the workflow will fail because the PR needs some updates.  Instructions for
+    # updating the PR will be available in the build log, the workflow summary and as a PR
+    # comment if the PR came from a branch (not a fork).
+    # This workflow assumes:
+    #  - The main README.md is at the root of the repo
+    #  - The README contains a contribution guidelines and usage examples section
+    uses: im-open/.github/.github/workflows/reusable-build-and-review-pr.yml@v1
+    with:
+      action-name: ${{ github.repository }}
+      default-branch: main
+      readme-name: 'README.md'
+
+      # The id of the contribution guidelines section of the README.md
+      readme-contribution-id: '#contributing'
+
+      # The id of the usage examples section of the README.md
+      readme-examples-id: '#usage-examples'
+
+      # 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 increment-version-on-merge.yml.
+      files-with-code: 'action.yml,package.json,package-lock.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 increment-version-on-merge.yml.
+      dirs-with-code: 'src,dist'
+
+      # The npm script to run to build the action.  This is typically 'npm run build' if the
+      # action needs to be compiled.  For composite-run-steps actions this is typically empty.
+      build-command: 'npm run build'

.github/workflows/increment-version-on-merge.yml

@@ -1,60 +1,47 @@
 name: Increment Version on Merge
+run-name: "${{ github.event.pull_request.merged && 'Increment version for' || 'Closing' }} PR #${{ github.event.pull_request.number }}"
 on:
   # https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
-  # - GitHub’s standard pull_request workflow trigger prevents write permissions and secrets
-  #   access to the target repository from public forks.  PRs from a branch in the same repo
-  #   and forks of internal/private repos are not limited the same way for this trigger.
-  # - The pull_request_target trigger allows the workflow to relax some restrictions to a
-  #   target repository so PRs from forks have write permission to the target repo and have
-  #   secrets access (which we need in order to push a new tag in this workflow).
-  # - For this workflow, the elevated permissions should not be a problem because:
-  #    - Our im-open repositories do not contain secrets, they are dumb actions
-  #    - Require approval for all outside collaborators' is set at the org level so someone
-  #      with Write access has a chance to review code before allowing any workflow runs
-  #    - This workflow with elevated Write permissions will only run once the code has been
-  #      reviewed, approved by a CODEOWNER and merged
+  # 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:
-      - 'dist/**'
-      - 'src/**'
-      - 'action.yml'
-      - 'package.json'
-      - 'package-lock.json'
+  # 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:
-    if: github.event.pull_request.merged == true && github.event.pull_request.base.ref == 'main'
+    uses: im-open/.github/.github/workflows/reusable-increment-version-on-merge.yml@v1
+    with:
+      default-branch: main
 
-    runs-on: ubuntu-latest
+      # 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 increment-version-on-merge.yml.
+      files-with-code: 'action.yml,package.json,package-lock.json'
 
-    steps:
-      # Generally speaking, when the PR contents are treated as passive data, i.e. not in a
-      # position  of influence over the build/testing process, it is safe to checkout the code
-      # on a pull_request_target.  But we need to be extra careful not to trigger any script
-      # that may operate on PR controlled contents like in the case of npm install.
-      - name: Checkout Repository
-        uses: actions/checkout@v3
-        with:
-          ref: main
-          fetch-depth: 0
-
-      # See https://github.com/im-open/git-version-lite for more details around how to increment
-      # major/minor/patch through commit messages
-      - name: Increment the version
-        uses: im-open/git-version-lite@v2
-        id: version
-        with:
-          github-token: ${{ secrets.GITHUB_TOKEN }}
-          default-release-type: major
-
-      - name: Create version tag, create or update major, and minor tags
-        run: |
-          git config user.name github-actions
-          git config user.email [email protected]
-          git tag ${{ steps.version.outputs.NEXT_VERSION }} ${{ github.sha }}
-          git tag -f ${{ steps.version.outputs.NEXT_MAJOR_VERSION }} ${{ github.sha }}
-          git tag -f ${{ steps.version.outputs.NEXT_MINOR_VERSION }} ${{ github.sha }}
-          git push origin ${{ steps.version.outputs.NEXT_VERSION }}
-          git push origin ${{ steps.version.outputs.NEXT_MAJOR_VERSION }} -f
-          git push origin ${{ steps.version.outputs.NEXT_MINOR_VERSION }} -f
+      # 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 increment-version-on-merge.yml.
+      dirs-with-code: 'src,dist'