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

2022/10/08に公開約2,000字2件のコメント

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

その際に呟いたやつが今回の記事の内容です
https://twitter.com/katzchum/status/1564933547751665665

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

https://twitter.com/Shitimi_613/status/1564934755271196672

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

他のCIにはあったアレ

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

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

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

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

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

https://github.com/marketplace/actions/workflow-run-cleanup-action
https://github.com/marketplace/actions/skip-duplicate-actions

アレ = concurrency

オフィシャルの日本語ドキュメントはこちら
https://docs.github.com/ja/actions/using-jobs/using-concurrency

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

一般的な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についてもっと良い書き方や、こういうユースケースでも使っています!というのがあれば、コメントを頂けると助かります。

脚注
  1. 自由度が高いとあれこれ考えてしまう自分みたいな人 ↩︎

Discussion

自由度が高いとあれこれ考えてしまう自分みたいな人

ひとつの単語から色々連想できますからね。
自分が連想するということは、他人にも連想の余地を与えてしまいますからね。
フレーズがよいので自分も使っていこうと決意しました。

ありがとうございます。
ちょっとあれこれ考えていた内容を補足させて頂きます。

concurrencyは便利なのですが、設定を追加したworkflow以外にも影響を与える機能なので注意が必要です。

チーム開発だと他のメンバーがworkflowを追加することもあり、コピペで作成されたりすると知らない間に追加されたworkflowではなく既存のworkflowが失敗(成功にならず停止)する可能性も出てきます。

なので、今後追加されるであろうworkflowやそれに携わる全ての人の動きまでは予測できないと思い、あれこれ考えた感じですね。

便利な機能だけど、影響が大きいので最初からベストプラクティスを抑えておいてからプロジェクトに普及させたいという思いでした

ログインするとコメントできます