Github Actions
(Github Actions) Self-Hosted Runnerが失敗した場合にGithub Runnerで代わりに実行する
最近、会社で利用していたJenkins CI/CDをGithub Actionsに転換する際、Self-Hosted Runnerを使用することになりました。 Self-Hosted Runnerとは？ Self-Hosted Runnerとは、その名の通り、自己ホスティングされたランナーを意味します。Github Actionsを実行するとき、GitHubが提供するRunnerではなく、ユーザーが自らホスティングしたマシンを使用するのです。 ユーザーのコンピュータを直接使用するため、環境的な制約やキャッシュなどの問題が発生することもありますが、GitHub Runnerに比べて速く、（電気代を除けば）無料で使用できるという利点があります。 Self-Hosted Runnerを使用する理由 現在、Jenkinsで問題になっていたのはテストにかかる時間でした。テスト時間を削減するために既存のコードをリファクタリングして30分から10分程度まで3分の1に短縮しましたが、どんどん増えるテストコードとリポジトリのテストのためにTestcontainerを導入し、やむを得ず実行時間が19分に延びてしまいました。 問題は、これらのテストプロセスが、PRを出すときだけでなく、デプロイ時にも含まれているため、デプロイ時間が30分に達するほど長くなることです。 そこで、こうした問題を解決するためにSelf-Hosted Runnerを使用することに決定しました。 会社にある既存の機器を使うのも良く、Jenkinsの場合、AWS EC2インスタンスを使用していましたが、EC2インスタンス対比で安価で（電気代）、遥かに性能が優れているというメリットがありました。（セッティングも簡単です） 会社に余った機材がない場合、まったく別の話になるでしょう。私たちの会社では基本的にビルドランナーに使える余ったマシンがあったためこの選択をしました。実務では、GitHubが提供する高スペックのランナーを使用するのとコンピュータ購入費用を比較することが先行すべきです。 もちろん、JenkinsにSelf-Hosted Runnerをつける方法もありますが、固定的なマシンの数を指定しなければならないなどの制約があり、動的に伸縮できるGithub Actionsを選択しました。 問題点 問題はSelf-Hosted Runnerが常に正常動作しないことです。もちろん、GitHub Runnerにもその点はありますが、会社で直接管理するマシンであるため、LANケーブルの老朽化などでしばしばマシンがダウンすることがあります。 その度に何が起こっているのかも分からないマシンを再度点検して持ち直すのはかなり厄介な作業です。 組織ランナーの場合、そのプロジェクトだけでなく、全体的なプロジェクトに影響を与える可能性があるため、待ち時間と時間による損失はさらに大きくなるでしょう。 そこで、この問題を解決するために、Self-Hosted Runnerがダウンしている時、Github Runnerで代わりに実行するフォールオーバー方法を探しました。 難関 問題は、Github Actionsが公式にはSelf-Hosted Runnerが何らかの理由でオフラインになった場合にGithub Runnerで代わりに実行する機能を提供していないことです。 ランナーグループをいくつかまとめて同時に実行できる機能はサポートしています。ただ、結局同時実行に過ぎないため、多用すると未使用のランナーに対する費用を支払わなければならないでしょう。（特に基本のランナーは時間がかかるため、時間による費用も高くなるでしょう。） 解決策 無ければ歯茎で何とかしろと言うけれど、前面でランナーの状態を直接チェックした後でルーティングするとどうだろう？というアイデアに基づいてアクションを構築しました。 フローは次のようになります。 ubuntu-latestはGithub Runnerを意味し、self-hostedはSelf-Hosted Runnerを意味します。 状態チェックはGithub APIで提供されるランナー情報をもとにチェックするように構成しました。
2024年10月21日
Github PR（プルリクエスト）のタイトル、イシュートタイトルに応じたラベルの自動設定方法
会社のプロジェクトを見ていると、便利に使われているアクションがあり、それについて投稿します。 それは、PRのタイトルに応じてラベルを自動で設定してくれるアクションです。 通常、GithubイシューやPRに分類を簡単にするためにラベルを付けることがありますが、これは後にどのような種類のイシューやPRがあったのか、履歴の追跡やフィルタリングを簡単にするためです。 （イシューやPRが見た目も良くなります） 会社では手作業で毎回ラベルを付けると抜け漏れがあったり、間違って付けることもあります。以下では、PR、イシュートタイトルに基づいてラベルを自動で設定するアクションを紹介します。 PR Labeler Action ラベルを自動で付けるために Auto Labeler というものを使用します。 このアクションはGithub Marketplaceに登録されており、PR、イシュートタイトルに応じてラベルを自動で設定する機能を備えています。 使い方はとても簡単です。 まず、.github/workflow/labeler.yml を作成し、以下のように記述します。ファイル名やnameなどは、自分が設定したいように指定できます。 .github/workflows/labeler.ymlname: Community on: issues: types: [opened, edited, milestoned] pull_request_target: types: [opened] jobs: labeler: runs-on: ubuntu-latest steps: - name: Check Labels id: labeler uses: jimschubert/labeler-action@v2 with: GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} このファイルはWorkflowファイルなので、Pushすると指定した名前である Community というアクションが生成されます。
2024年5月27日
PR(Pull Request)に自動でassigneeとreviewerを指定する方法
会社で開発をしていると、些細なことが面倒に感じることがあります。 例えば特定のラベルを付けるルールがあったり、PRを提出する際に特定のAssigneeやReviewerを指定しなければならない場合など、代表的な例としては簡単だけれど面倒で忘れやすい…？そんなことだったように思います。 会社に初めて入った時もそうでしたが、この部分にはどのラベルを付けるべきか、Reviewerに誰を指定するべきかといった部分がややこしかったようです。 Auto Assign Action 実はGithubの機能ではこれらを自動で指定することはできません。しかし、Github Actionsのイベントを利用すれば、PRがオープンされる際をターゲットに特定のアクションを実行させることができます。 実際に実行するアクションは自作することもできますが、既にその機能を実装しているものがあり、それを使用すれば便利にAssigneeとReviewerを指定できます。 この例では、Github ActionsマーケットプレイスにあるAuto Assign Actionを使用します。 仕様を見ると、Assignee、Reviewerをグループごとに指定して割り当てることもできます。 一つのリポジトリを複数のチームで管理している場合、便利に使うことができるでしょう。 また、include、ignoreするラベルやキーワードを定義できるため、Auto Assign Actionを必要としないPR（例：リリースPR、テストPRなど）は無視させることができます。 使用法 このアクションを使用するためには、アクションを設定する設定yaml、およびGithub Actionsを使用するためのGithub Workflow yamlファイル合計2つのファイルを準備する必要があります。 .github/auto_assign.yml# Reviewer自動割り当て設定 addReviewers: true # AssigneeをAuthorに設定 addAssignees: author # Reviewer追加するユーザーリスト reviewers: - YangTaeyoung # 自分の名前 - {チームメンバー_Github_Username_1} - {チームメンバー_Github_Username_2} - {チームメンバー_Github_Username_3 ...} # 追加するレビューアの人数 # 0に設定するとグループ内のすべてのレビューアを追加します（デフォルト：0） numberOfReviewers: 0 # Pull Requestに以下のキーワードが含まれている場合、レビューア追加プロセスをスキップします skipKeywords: - exclude-review # レビューを除外するキーワード設定 これ以外にも様々な条件下で自動割り当てを行うことができます。
2024年5月23日