こんにちは、2022年4月にフォースタートアップスにジョインしたエンジニアの八巻（@hachimaki37）と申します。主に社内向けプロダクト「タレントエージェンシー支援システム（SFA/CRM）」のシステム開発を担当しております。
今回は初めてGithubActionsの改修チケットに関わることになり、途中ヒイヒイ言いながらも試行錯誤して解決に至った話について書いていければと思います。
本題に入る前に、まずは「GithubActionsとは？」と「GithubActionsの導入経緯について」簡単に述べていきたいと思います。
GithubActionsとは？
GithubActionsはGithubが2019年に出したCI/CDサービスです。
GitHub Actionsを使用すると、ワールドクラスのCI / CDですべてのソフトウェアワークフローを簡単に自動化できます。 GitHubから直接コードをビルド、テスト、デプロイでき、コードレビュー、ブランチ管理、問題のトリアージを希望どおりに機能させます。
引用元：https://github.co.jp/features/actions
当社の導入経緯について
弊社のユースケースですとGithubActionsの方にコストメリットがあることがわかったため「コスト削減」を目的にCircleCIからGithubActionsへ移行しました。
導入されたがこんな問題があった
当社の場合、pushトリガー + ブランチのフィルタ条件を用いて発火条件を制御しております。
サンプルコード
name: staging Build and Deploy
on:
push:
branches:
- staging_axx**
- staging_bxx**
- staging_cxx**
※サンプルコードをベースに以下話を進めています
1. Github上からブランチを作成するとGithubActionsが発火しない
pushを発火条件としているため、Github上でのブランチ作成（＝pushなくGithub上にブランチができあがる）がこの条件にヒットせず、発火されない
2. ブランチのpush順序をミスるとGithubActionsが発火されない
▶︎正しい順序
- ローカルPC上で、作業用ブランチをmasterから作成する(feature/hogehoge)
- ローカルPC上で、stagingブランチを作業用ブランチから作成(staging_axx/hogehoge)しpushする
- 作業用ブランチ(feature/hogehoge)をpushする
▶︎誤った順序
- ローカルPC上で、作業用ブランチをmasterから作成する(feature/hogehoge)
- 上記3を先に実行する（作業用ブランチ(feature/hogehoge)をpushする）
- 上記2を次に実行する（ローカルPC上で、stagingブランチを作業用ブランチから作成(staging_axx/hogehoge)しpushする）
当社では、github-flowに沿った運用を採用しております。誤った順序でpushした場合、pushトリガーの条件にヒットせず、GithubActionsが発火されない
上記の体験から非常に使い勝手が悪い！！そんな声が開発メンバーから上がっておりました。
どんな状態を目指したのか
シンプルに「必要な時に、適宜GithubActionsを発火させたい」ということです。
最初のアイディアは、pushトリガーのようにブランチフィルタを使えば簡単に実現できる！と思っていたのも束の間、実現にあたってこんな問題を抱えておりました。
The create event does not support branch filter and tag filter.つまり、pushトリガーのようなブランチのフィルタ条件が、createトリガーにはサポートされていなかったのです。悲しい...
調査と試したこと
ここからヒイヒイ言いながら試行錯誤の日々が始まりました。
- createトリガーを追加したらどのような動作が走るのかまず試してみる
- ん？createトリガーってブランチフィルターをそもそもサポートしてないんじゃ無理くないか？と思いながら、いい解決方法ないかなぁとググりまくる。あった！→https://github.com/orgs/community/discussions/26286
- jobs自体に条件を追加してみる
- stepsに条件を追加してみる
- 良い記述方法を模索する
- 条件を追加してもSyntax errorがたくさんでる..そもそもどうやって記述すればいいのだろうか
などなど、試行錯誤をしながら進めておりました。
苦労したこと
- 適切な箇所（jobs, stepsなど）への条件追加を模索したこと、追加したはいいもののSyntax errorが多発するなど、最初は構文理解に苦労しました。「コードを追加してみてpush」「Github上からブランチをcreateする」を繰り返すことで、徐々に理解に繋がりました。
- 全てのブランチでjobsが発火してしまう。当たり前ですが、createトリガーを追加すると全てのブランチを作成したタイミングでjobsが発火してしまうため、頭を悩ませました。ここは記事（https://github.com/orgs/community/discussions/26286）を参考にコードを書いてみて、特定のブランチ名だと「success」「skipped」になる方法で、解決に至りました。
実装したサンプルコード
createされたブランチが、以下のブランチ名にマッチする場合に発火するよう、条件を追加しました。
name: staging Build and Deploy
on:
push:
branches:
- staging_axx**
- staging_bxx**
- staging_cxx**
create:
jobs:
build:
name: Build and Push
runs-on: ubuntu-latest
timeout-minutes: 30
environment: staging
if:
contains( github.ref_name, 'staging_axx/' ) ||
contains( github.ref_name, 'staging_bxx/' ) ||
contains( github.ref_name, 'staging_cxx' )
env:
省略
steps:
- name: Checkout
uses: actions/checkout@v2
- name: hogehoge
run: test1
- name: foofoo
run: test2
- name: fugafuga
run: test3
createされたブランチがマッチした場合
ブランチ名：staging_axx/fix-hogehoge
createトリガーが発火し、GithubActionsが実行される
createされたブランチがマッチしなかった場合
ブランチ名：staging_zxx/fix-hogehoge
createトリガーが発火せず、skipされる
あとがき
正直結構な時間を費やしてしまいチームにご迷惑をおかけしてしまいましたが、リリース後、チームの方からは嬉しい嬉しいフィードバックがありました！！！
今回記述した設定ですと、対象ブランチの数が増加するとコードが冗長になるので、リファクタリングができないか？と考えておりますが、問題自体は無事解消に至りました。
私自身エンジニア歴は3年ほどで、今まではサーバーサイドをメインに経験を積んできました。次のステップを考えた際にフルスタック（コーディング以外も含む）に動けるエンジニアへの成長を目指し、フォースタートアップスにジョインしました。
今回初めてGithubActions周りのチケットに携わりましたが、直近はVue.jsなどフロントエンドにも関わる機会が増え、嬉しい成長痛を日々感じ業務にあたっております。
なかなか経験のないチケット着手はワクワクと不安の感情が入り混じりますが、当社では初めてのチケットの場合「good first issue」を付け、初めてでも取っ掛かりやすい環境を構築しております。
まだまだやるべきこと、やりたいことがたくさんあります。ぜひ一緒に成長していきませんか？ 当社は採用大募集中です。ご興味ありましたらぜひ一度カジュアルにお話できたらと思います。
