Github action template

GitHub action is very easy to set up in general. However, when customization is needed, the configuration can become complicated very quickly. For example, I recently found that it is not easy to make the actions run only when a PR is ready for review. The default behavior of GitHub actions is to run on every push, which can be inefficient and time-consuming.

Here is the template I eventually came up with:

name: CI
 
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
    paths:
      - 'apps/**'                   # code
      - 'packages/database/**'      # dependent libraries
      - - 'package-lock.json'       # dependency lock
      - '.github/workflows/ci.yaml' # action definition
    types:
      - opened
      - reopened
      - synchronize
      - ready_for_review
      - review_requested
  workflow_dispatch:
 
concurrency:
  group: ${{ github.workflow }}-${{ github.ref || github.run_id }}
  cancel-in-progress: true
 
jobs:
  test:
    if: ${{ !github.event.pull_request.draft || github.event.pull_request.requested_reviewers[0] || github.event.pull_request.requested_teams[0] }}
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

There are a few gotchas in the above configuration.

• Having the ready_for_review trigger alone will not automatically launch the action when a PR is created with ready-to-review mode. This trigger only listens to the event when the PR is marked as ready for review.
• Because of the limitation of the ready_for_review trigger, the opened trigger is needed as well to accommodate the case when a PR is created in ready-to-review mode.
• With the opened trigger, the action will always run, even when the PR is in draft mode. So an if condition is needed on the job level: if: ${{ !github.event.pull_request.draft }}
• Even with opened and ready_for_review, the action will only run once. When new commits are pushed to the PR, it will not run again, which was also a bit surprising to me. Adding the synchronize trigger resolves this issue.

The bottom line is that all these triggers are event-based conditions that will only launch the action once. They don’t control the action based on the state of the PR (whether it is a draft, or whether it has assigned reviewers). This was my misunderstanding. But it is also confusing because the GitHub documentation does not have a clear explanation of what each trigger type does.

This instance provides another evidence that replacing human engineers with AI agents is very difficult, even for simple tasks like customizing a GitHub action trigger.