mediba Advent Calendar 2020 の18日目担当の @h-sugawara です。
担当している各種プロジェクトでは、CI/CD に CircleCI というサービスを使わせて頂いています。
しかし、最近、諸事情により CircleCI から Github Actions への移行を検討していて、Github Actions の導入検証を行いました。
今回は、Github Actions で頻出して使うことが多くて調べたものを、毎度調べ直すのが面倒だったため、情報を集約する Tips を作成しました。

Workflow Tips

コミットにソースコードを含む開発用ブランチをプッシュした時に実行する

開発用ブランチfeature/hogehogeにソースコードbatch/foobar/main.goを含むファイルをコミットして、Github へプッシュした時に、テストや構文チェックを行う Workflow を実行させたいとします。
このような場合、次の例のようにプッシュイベントのトリガーを設定します。

on:
  push:
    branches:
      - 'feature/*'
    paths:
      - '**.go'

on.push.branchesの'feature/*'は、feature/から始まるブランチが対象です。
しかし、__*は/を除く0文字以上の文字列を示すフィルタ__であるため、feature/issue-1234/hogehogeのようなブランチは対象外となることに注意が必要です。
これらの対象外となるブランチも含める場合は、0文字以上のすべての文字列を対象とする**を用いて'feature/**'とします。

on.push.pathsも同様のルールで、上述の例の場合はすべての.goファイルがコミットに含まれているかが対象となります。
これを、'*.go'と書き換えた場合は、レポジトリのルートにある.goファイルだけが対象となります。

指定ブランチ以外をプッシュした時に実行する

特定のブランチのプッシュを無視する場合は、on.push.branches-ignoreで指定します。
ただし、これをトリガーに設定すると Github Actions の仕様上、__タグのプッシュはすべて無視される__ことに留意しておきましょう。
タグのプッシュも含めるには、次のようにon.push.tagsに'*'または'**'を、トリガーに設定します。

on:
  push:
    branches-ignore:
      - 'develop'
      - 'release/**'
    tags:
      - '*'

このようにすると、例えば、feature/から始まるブランチをプッシュしたり、v1.0.0のようなタグをプッシュしたりすると Workflow が実行されます。
反対に、developブランチやrelease/から始まるブランチをプッシュしても Workflow は実行されません。
なお、タグのプッシュが無視されても構わない場合は、on.push.tagsの指定は不要です。

指定タグ以外をプッシュした時に実行する

特定のタグのプッシュを無視する場合は、on.push.tags-ignoreで指定します。
前述のbranches-ignoreと同様に GitHub Actions の仕様により、__ブランチのプッシュはすべて無視__されます。
ブランチのプッシュも含めるには、下記のようにon.push.branchesに'**'を、トリガーに設定します。
※'*'を指定した場合、ブランチ名に/が含まれるとうまく動かないため、'**'の利用を推奨。

on:
  push:
    branches:
      - '**'
    tags-ignore:
      - 'dev-*'
      - 'stg-*'

この設定例では、developブランチや、feature/またはrelease/などから始まるブランチをプッシュしたり、v1.0.0のようなタグをプッシュしたりすると Workflow が実行されます。
反対に、dev-やstg-で始まるタグがプッシュされた場合は、Workflow は実行されません。
もちろん、特定のタグ以外のタグのプッシュを対象とするだけなら、on.push.branchesは不要です。

プルリクエストがマージされた時に実行する

プルリクエストのマージをトリガーとする Workflow を作成する時は、次の2点に注意が必要です。

compare ブランチ（マージ元）ではなく、base ブランチ（マージ先）が対象である
プルリクエストイベントのアクティビティタイプにはマージされたことを示すものはない

そのため、以下の例のように、on.pull_request.typesがclosedであり、jobなどでgithub.event.pull_request.mergedがtrueであることを確かめる必要があります。

on:
  pull_request:
    branches:
      - my_base_branch
    types:
      - closed

jobs:
  my_job_name:
    runs-on: ubuntu-latest
    if: github.event.pull_request.merged == true
    steps:
      - name: my_step_name
        run: echo "Hello world!"

renovate などのツールやプルリクエストの作成などを定期的に実行する

on:
  schedule:
    - cron: '*/15 * * * *'

Job Tips

2つ以上前に実行された Job の出力値を参照する

例えば、first_job、second_job、last_jobの順で Job を実行するとします。
この時、last_jobのneedsに、直前に実行されることを意図してsecond_jobだけを指定すると、Job の実行順はその通りになります。
しかし、second_jobの前に実行されたfirst_jobの出力値は参照できません。
なぜなら、Job が参照できる出力値は、依存関係によって以前に実行したすべての Job ではなく、needsで指定した Job のみだからです。
そのため、実行する Job から見て依存関係にあるすべての Jobを needsに指定する必要があります。

jobs:
  first_job:
    runs-on: ubuntu-latest
    outputs:
      first_val: ${{ steps.echo_step.outputs.first }}
    steps:
      name: set output
      id: echo_step
      run: echo "::set-output name=first::hogehoge"

  second_job:
    runs-on: ubuntu-latest
    needs: [first_job]
    outputs:
      second_val: ${{ steps.echo_step.outputs.second }}
    steps:
      name: set output
      id: echo_step
      run: echo "::set-output name=second::foobar"

  last_job:
    runs-on: ubuntu-latest
    needs: [first_job, second_job]
    steps:
      name: echo before job output
      run: |
        echo "${{ needs.first_job.outputs.first_val }}"
        echo "${{ needs.second_job.outputs.second_val }}"

直前の Job の結果が success 以外でも必ず実行する

Job の実行条件は、if: success()（成功時のみ実行）がデフォルトで設定されています。
そのため、jobs.<job_id>.needsで指定した Job のいずれか一つでも実行結果がsuccess以外になった場合、<job_id>の実行はスキップされます。
必ず実行させる必要がある Job には、下記のようにif: always()を指定しましょう。

jobs:
  first_job:
    runs-on: ubuntu-latest
    steps:
      name: failure job
      run: exit 1

  second_job:
    runs-on: ubuntu-latest
    steps:
      name: success job
      run: exit 0

  last_job:
    runs-on: ubuntu-latest
    needs: [first_job, second_job]
    if: always()
    steps:
      name: echo
      run: echo "running second_job."

この方法は、テストやビルド、デプロイなどの Job の後に、Slack などでそれらの実行結果を通知する Job を実行する場合に活用できます。