博士

やあ、ロボ子。今日はGitHub ActionsでCIスクリプトを書き直した話をするのじゃ。

ロボ子

博士、こんにちは。CIスクリプトの書き直し、大変そうですね。

博士

それがの、なかなか複雑だったみたいじゃ。マージキューとか、複数のランナーとか、RustビルドにDockerイメージ、それに重い統合テストまであったらしいぞ。

ロボ子

色々な要素が絡み合っているんですね。記事によると、GitHub Actions自体は要件を満たせるものの、設定やデバッグが難しかったと。

博士

そうなんじゃ。「GitHub Actionsは技術的には要件を満たせるが、設定が難しく、デバッグが困難」とある。特にmainブランチをクリーンに保つためにGitHubのmerge queueを使うのが一苦労だったみたいじゃな。

ロボ子

CIをキューに入る前と、キューの中で再度実行する必要があるのに、GitHub Actionsでは両方の実行を必須にするのが難しいとは、どういうことでしょうか？

博士

そこがミソじゃ。解決策は、両方のフェーズでジョブに同じ名前を付けることだったらしいぞ。ちょっとトリッキーじゃな。

ロボ子

なるほど。それから、GitHub Actionsのセキュリティモデルも複雑で理解しにくいと書かれていますね。

博士

`GITHUB_TOKEN`の権限とかじゃな。不要な権限を削除することが推奨されているけど、どの権限が何を保護しているか不明確だなんて、困ったものじゃ。

ロボ子

ワークフローの権限はアクション自体には依存しないというのも、意外でした。カスタムトークンが必要になる場合があるのに、理由が不明確なのも気になります。

博士

じゃろ？　セルフホストランナーをパブリックリポジトリで使用しない方が良いというのも、セキュリティを考えると当然じゃな。

ロボ子

DockerとGitHub Actionsの組み合わせについても、問題が多いと指摘されていますね。ファイル権限の問題や、$HOMEディレクトリの移動など、色々あるようです。

博士

`container`フィールドにも制限があるみたいじゃし、YAMLで記述されたロジックは複雑になりやすい。静的チェックが不足しているのも痛いところじゃな。

ロボ子

CIをローカルで試すことが難しいため、デバッグにはテストリポジトリを使用するというのは、良いプラクティスですね。

博士

ワークフローを小さく保ち、成果物を再利用することで、CIの時間を短縮できるのも重要じゃ。ワークフローから別のワークフローを呼び出す場合、シークレットはデフォルトで共有されない点も注意が必要じゃな。

ロボ子

新しいCIスクリプトはマージ時間を大幅に短縮したとのことですが、プロセス全体としては時間と労力がかかったようですね。

博士

まさに「CIの道のりは遠く、険しい」って感じじゃな。でも、最後に笑えればそれで良し！

ロボ子

そうですね！　ところで博士、CIスクリプトのデバッグで一番苦労したのは何ですか？

博士

それはの、エラーメッセージが「原因不明」って表示された時じゃ！　もう、お手上げなのじゃ！