業務で役立つ…かもしれない？！GitHub Actions Tips 集
matrix job
- 似てるけど微妙にパラメータが違うジョブ
- まとめて並列実行したい
- matrix jobでパラメータを差し替えながら並列実行できる
- バージョンとかOSだけ変えてまとめて動かすとか
- 複数の条件の組み合わせで動かせる
- inputにjsonを使えるのが便利
- workflowの外からデータを注入できる
- secretsを出し分けたい場面がある
- matrixではkeyだけ指定して使うといい
動的job実行
- Branch Protection
- PR作成時にCIが通らないとマージできないとか
- 条件にjobを指定できる
- jobをフィルタリングしたくなることがある
- 実行時間や課金面で毎回全部動かしたいわけではない
- pathsフィルター
- 特定のファイルが更新された時に実行させることができる
- 対象外だった時にworkflowが動かずpendingでマージがブロックされてしまう
- pathsフィルターとBranch Protectionの相性が悪い
- paths-filterを使ってworkflowは実行しつつjobをフィルターできる
- Status Check Job
- このjobをpass/failさせることでBranch Protectionを機能させる
- passの条件
- exit 0で終わる
- jobをスキップして実行されない
GITHUB_TOKEN
CI/CD のセキュリティや Developer Experience を改善するツールやプラクティス
- @szkdashさん
PRコメントでCIの結果通知
- CIがこけたら原因をPRにコメントしたい
- ログ見に行くよりすぐ見れてわかりやすい
- github comment
- コメントのテンプレートも用意できるので使うと見通しがよくなる
- 古いコメントを非表示にして新しくコメントできる
複数リポジトリのメンテナンス
GItHub Actionsのセキュリティベストプラクティス
- ベストプラクティス
- jobのpermissionsを最小限
- secretの公開範囲を最小step/job
- Actionのバージョンをfull commit hashで固定する
- ghalintでチェックできる
- CIで実行してセキュリティを担保
- ツールのバージョン固定
- ツールが汚染されてもいきなり反映されない
- コードを変更してないのにCIが壊れるようなことを防ぐ
- バージョンやタグもあるが変更されることがある
- フルコミットハッシュが一番安全
- コードコメントでバージョンを書けばRenovateも見てくれる
- バージョンはパッチまでしっかり書くと更新時の差分が見やすい
CIで使うツールの管理
- バージョン固定
- latestは突然壊れる
- ツールの自動アップデート
- shellでやるのは面倒
- aqua
- yamlでツールとバージョンを管理できる
- https://github.com/aquaproj/aqua
一歩先のセキュリティ
- CIを書き換えられないようにする
- 任意のコード実行を防ぐ
- 強い権限与えないといけない時特に
- pull_request_target event
- feature branchのスクリプトを実行するのは危険
古いrevisionでの実行を防ぐ
- defaultブランチの最新のHEADかチェック
CI/CDがあたりまえの今の時代にAPIテスティングツールに求められていること
runn
- https://github.com/k1LoW/runn
- yamlでシナリオを書いて操作できるツール
- コマンドラインから実行できる
- APIのシナリオテストができる
runnの機能
- 1バイナリで作られてる
- さまざまなプロトコルに対応
- OpenAPI Specライクなシナリオ
- 複数のシナリオが想定されている
- 分割実行
- サンプリング実行
- ランダム実行
- プロファイルの取得
- ステップ実行できる
APIテストのモチベーション
- アプリケーションの外側からテストしたいというニーズ
- スモールテストよりコストが高い
- 実装コスト
- 環境整備が面倒
- 実行コスト
- 実装コスト
- CIでの自動実行が前提になってる
- コンピューティングリソースは気にならなくなった
APIテスティングツールに求められること
ChainingRequestに対応していること
親和性の高いテストダブル環境
- 規模が大きくなりがち
- テストダブルをアプリの外で構築できると望ましいが難しい
- Postmanはstubサーバのサポートがある
- runnはないので自前でstubサーバ動かしてやる
テストケースにIDがあること
- テストを一意にできるIDが必要
- 全てを毎回実行するのはコストが高い
- IDとメトリクスの連携
- 特定のものだけリトライとか
- 実行時間を特定するためにとか
- よく失敗するのを先にとか
- IDを使うと柔軟にできる
- runnは自動で動的に生成してる
APIスキーマとの連携がある
ポータビリティがある
- 開発環境とCI環境で同一の環境にしやすいこと
- 負荷試験としても活用できる
- 本番強への外形監視/計測として使える
- runnではいろんな環境で使えるようにしてる
リリース戦略を支えるCI/CDパイプライン
- @katzchumさん
リリース管理のつらみ
- システムが複雑になり依存が増えると管理が複雑になる
- リリース判断できる人が固定化されてくる
リリース戦略の事例
- 複数バージョンが並行するプロダクト
- クライアントによってバージョンが違う
- リリーストレイン
- リリースの日が決まっていて間に合ったものだけリリースする
- ブランチカットするタイミング
- リリース日が未定な状態でもタグをつける
- 開発環境にデプロイするタイミングでタグつける
- タグはOSSの開発スタイルに倣う
- セマンティックバージョニング
- tagpr
- リリース用のPRがCIで作られる
- マージするとtagができる
- https://github.com/Songmu/tagpr
