tree: b342952abe93ecc611900e360212b3c8a2a05646 [path history] [tgz]

.github/workflows/README.md

Running Workflows Manually

Most workflows will get kicked off automatically when you open a PR, push code, or on a schedule.

If you would like to manually trigger a job, you have 2 options:

Trigger Phrases: Many jobs have trigger phrases associated with them (e.g. Run XYZ PreCommit). These will appear in statuses of previous PR runs of that check. You can trigger the job on any PR by commenting that trigger phrase in the PR.
Committers only - Manual triggering: Any committer can start any job with a workflow_dispatch trigger defined (all jobs should have these). To do so, navigate to the Actions tab, click on your desired workflow in the left navigation bar, and then click Run Workflow.

Guidelines for Adding or Modifying Workflows

On top of normal Actions workflow steps, all new CI workflows (excluding release workflows or other workflow automation) should have the following:

Name and phrase set via matrix for re-run to work (See below)
A set of specific triggers
An explicit checkout step
A set of GitHub token permissions
Concurrency Groups
Comment Triggering Support

Each of these is described in more detail below.

Name and Phrase

Due to specifics on how the comment triggered rerun is handled it is required that all jobs have name and phrase set via matrix elements. See the following example:

jobs:
  beam_job_name:
    name: ${{ matrix.job_name }} (${{ matrix.job_phrase }})
    strategy:
      matrix:
        job_name: [beam_job_name]
        job_phrase: [Run Job Phrase]
    if: |
      github.event_name == 'push' ||
      github.event_name == 'pull_request_target' ||
      github.event_name == 'schedule' ||
      github.event_name == 'workflow_dispatch' ||
      github.event.comment.body == 'Run Job Phrase'
    steps:
      - uses: actions/checkout@v3
      - name: Setup repository
        uses: ./.github/actions/setup-action
        with:
          comment_phrase: ${{ matrix.job_phrase }}
          github_token: ${{ secrets.GITHUB_TOKEN }}
          github_job: ${{ matrix.job_name }} (${{ matrix.job_phrase }})

And in case when the workflow already utilizes matrix do the following:

jobs:
  beam_job_with_matrix:
    name: ${{ matrix.job_name }} (${{ matrix.job_phrase }} ${{ matrix.python_version }})
    runs-on: [self-hosted, ubuntu-20.04, main]
    timeout-minutes: 30
    strategy:
      fail-fast: false
      matrix:
        job_name: ["beam_job_with_matrix"]
        job_phrase: ["Run Job With Matrix"]
        python_version: ['3.8','3.9','3.10','3.11']
    if: |
      github.event_name == 'push' ||
      github.event_name == 'pull_request_target' ||
      github.event_name == 'schedule' ||
      startsWith(github.event.comment.body, 'Run Job With Matrix')
    steps:
      - uses: actions/checkout@v3
      - name: Setup repository
        uses: ./.github/actions/setup-action
        with:
          comment_phrase: ${{matrix.job_phrase}}
          github_token: ${{ secrets.GITHUB_TOKEN }}
          github_job: ${{ matrix.job_name }} (${{ matrix.job_phrase }} ${{ matrix.python_version }})

Notice how the matrix element of python_version is appended to the name.

Workflow triggers

GitHub allows workflows to define a set of triggers that dictate when a job should be run. For more info, see documentation here.

For the purposes of Beam, each CI workflow should define the following triggers:

A push trigger
A pull_request_target trigger
An issue_comment trigger (for issue created). This is needed for comment triggering support (see section below).
A scheduled trigger
A workflow_dispatch trigger

The push/pull_request_target triggers should only run when appropriate paths are modified. See https://github.com/apache/beam/blob/master/.github/workflows/beam_PreCommit_Go.yml#L4 for an example (you can copy and paste this into your workflow, you just need to change the paths).

Checkout step

Because we use the pull_request_target trigger instead of pull_request, we need an explicit checkout of the correct commit. This can be done as a step that uses the setup-action action in your workflow. See https://github.com/apache/beam/blob/0ee2dc73ec6f555a5bf1a643dffd37f4927be67e/.github/workflows/beam_PreCommit_Go.yml#L65-L70 for an example (you can copy and paste this into your workflow). Please make sure that you checkout the code before using the composite action.

Token Permissions

You should explicitly define the GitHub Actions token scopes needed by your job. For most jobs, this will be actions: write (needed for comment triggering support) and read permissions for all other options. See https://github.com/apache/beam/blob/907c5110163b0efe52e9e12127fd013c7fc455d7/.github/workflows/beam_PreCommit_Go.yml#L16 for an example (you can copy and paste this into your workflow).

Concurrency Groups

Concurrency groups are a way of making sure that no more than one Actions run is running per job/group at any given time (previous ones can be cancelled). To reduce resource usage, you should define the following concurrency group:

concurrency:
  group: '${{ github.workflow }} @ ${{ github.event.issue.number || github.event.pull_request.head.label || github.sha || github.head_ref || github.ref }}-${{ github.event.schedule || github.event.comment.id || github.event.sender.login}}'
  cancel-in-progress: true

this defines the following groups:

Each workflow will represent a different set of groups
Within each workflow, each PR will represent a single group
Within each non-PR run for a workflow, each commit will represent a set of groups
Within each commit, each push event, schedule event, and manual run event will represent a set of groups

Comment Triggering Support

In order to make it easier for non-committers to interact with workflows, workflows should implement comment triggering support. This requires 3 additional components beyond the ones mentioned above:

Each job should be gated on an if condition that maps to that workflow's comment trigger (example: https://github.com/apache/beam/blob/907c5110163b0efe52e9e12127fd013c7fc455d7/.github/workflows/beam_PreCommit_Go.yml#L38)
Each job should have the rerun action immediately after its checkout step. You can add a step that uses the setup-action action in your workflow, which encapsulates the checkout and rerun logic in one place. This should be gated on the comment trigger (example: https://github.com/apache/beam/blob/0ee2dc73ec6f555a5bf1a643dffd37f4927be67e/.github/workflows/beam_PreCommit_Go.yml#L65-L70)
Each job should have a descriptive name that includes the comment trigger (example: https://github.com/apache/beam/blob/ba8fc935222aeb070668fbafd588bc58e7a21289/.github/workflows/beam_PreCommit_CommunityMetrics.yml#L48)

Testing new workflows or workflow updates

Testing New Workflows

New workflows are not added to the UI on the Actions tab until they are merged into the repo's main branch (master for Beam). To test new workflows, we recommend the following pattern:

Fork the Beam repo
Add your proposed workflow to the main branch of your fork.
Run the workflow in the Actions tab of your fork using the Run workflow button.

Note: most workflows use self-hosted runners with the main and ubuntu labels to execute (example). If you are testing on a fork, you likely will not have self-hosted runners set up. To work around this, you can start using hosted runners and then switch over when you're ready to create a PR. You can do this by changing runs-on: [self-hosted, ubuntu-20.04, main] (self-hosted, use in your PR) to runs-on: ubuntu-20.04 (GitHub hosted, use for local testing).

Testing Workflow Updates

If you need to make more changes to the workflow yaml file after it has been added to the repo, you can develop normally on a branch (using your fork or the main Beam repo if you are a committer). If you are a non-committer, this flow has several caveats mentioned below. To do this:

Make your change on a development branch.
Navigate to your workflow in the Actions tab. If your changes are on a fork, navigate to the fork‘s Actions tab instead. If you don’t see the correct action, make sure that your fork‘s main branch is up to date with Beam’s master branch.
Click run workflow. Before clicking submit, update to run on your branch.

Note: If you run a workflow from your fork of Beam, it will not have access to secrets stored in the Beam repository. This will cause some things like authenticating to external services to fail, which may cause your workflow to fail. If you run into this issue, you can either:

Ask for a committers help to add the workflow to a branch on the main apache/beam repo.
Upload secrets to your repo mirroring the secrets used in the main Beam repo.
Wait until the changes are merged into Beam to test (this should only be done rarely).

Additionally, as mentioned above your fork likely will not have self-hosted runners set up. To work around this, you can start using hosted runners and then switch over when you're ready to create a PR. You can do this by changing runs-on: [self-hosted, ubuntu-20.04, main] (self-hosted, use in your PR) to runs-on: ubuntu-20.04 (GitHub hosted, use for local testing).

Workflows