⛔

GitHub Actionsで連続pushした時に止めるアレ

2022/10/08に公開2件

GitHub Actions

tech

大分時間が経ってしまいましたが、2022/8/31 に開催された stand.fm 主催の TECH STAND #9 GitHub イベントに参加しました。

その際に呟いたやつが今回の記事の内容です

有り難いことに直ぐにフォロー頂きました。

あまり纏まった記事が見当たらなかったので、自分用のメモとしてまとめます。

他のCIにはあったアレ

GitHub Actionsを利用する前は、TravisCIやCircleCIを利用していました。
移行してから随分使ってないので、記憶が定かではないのですが

連続してpushすると一つ前の実行中のjobが停止される

という機能が標準であった気がします。
この機能の名前は何と呼ぶのでしょうか？地味だけれども、ないと困るアレですｗ

GitHub Actionsのリリース直後にこちらの機能と [ci skip] が使えずに後発なサービスなのにーと不満を覚えていました。

その後にアレの機能を実装したカスタムアクションを組み込んで対応いました。
以下の様なactionを実際に組み込まれた方は多かったのではないかと思います。

アレ = concurrency

オフィシャルの日本語ドキュメントはこちら

これまたありがたいことに、イベントでフォロー頂いた @korosuke613 さんが挙動をスクラップにまとめてくれていました。
勝手ながら紹介させて頂きます。

一般的なconcurrencyの設定の仕方

concurrency 自体は、グループ名を細かく指定すれば複雑なworkflowであっても止める（待つ）所とそうでない所を色々制御できそうです。
ただworkflowの実行頻度が一番高いテストは単純なものが多く、逆にグループ名の付け方を悩む人 ^[1] もいると思います。
個人的にベストだと考えている設定内容はこちらです。

name: test
on:
  pull_request:
    types: [opened, reopened, synchronize]
    paths:
      - 'foo/**'
  push:
    branches:
      - develop

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

よくあるPR時とdevelopにmergeした時に動くworkflowの設定です。
これで1つのブランチで1つのワークフローが実行されるようになると思います。
workflow毎に設定変更しなくて済み、とりあえず入れておくかーという感じで使えています。

注意点として別のworkflowファイルでも name が同じだと、同じworkflowだと判断されて止まってしまいます。
例えば単体テストとE2Eテストで別workflowにした場合には、別の名前にしましょう。

最後に

自分の様に古いカスタムアクションを利用してworkflowをキャンセルしている人は移行をおすすめします。
キャンセルするカスタムアクション自体が一つのworkflowとして動くので、リソースは無駄ですし、待ち時間も微妙に伸びます。
やはり標準機能を使うのが正義かと。
concurrencyについてもっと良い書き方や、こういうユースケースでも使っています！というのがあれば、コメントを頂けると助かります。

脚注