GitHub Actions イントロ
- 必要になったときにすぐ使えるために
- 今は読むだけ
.github/workflows/
に foo.yaml
を置けばいい
yaml に直接 shell コマンドを書いたり、外部にある action を参照して使ったり、コンテナを使ったりできる
ビルドごとにクリーンな環境を立ち上げて動くので、リポジトリのファイルを触りたいなら checkout する action を使う
環境も os とかを設定できるが、mac はクソ高い
特に理由がない限りは ubuntu とかでいいだろう
jenkins みたいに特定のディスクに .git
ごとずっと置いてあってそこで作業するわけではない
push に限らず issue 発行時や pr コメントをトリガーにすることも可能
push はブランチを指定したり、issue は open や close のときに限ったりも可能
従来の jenkins pull request builder による ci/cd では push 検知のみだったり、
github webhooks はイベントは融通がきくが実処理を行う外部サーバとエンドポイントが必要だったりしたが、
github actions は github だけで設定からビルドまで行える
アクションを利用するときは yaml で uses: peaceiris/actions-gh-pages@v3
と指定する
これは https://github.com/peaceiris/actions-gh-pages を参照している
@v3
の部分は hash か branch か tag を指定できる
- ↑ 固定
- hash
- tag (
@v3.0.0
) - tag (
@v3
で v3 の最新となる ) - branch
- ↓ 不安定
固定するほど動作が安定するが、action 側の不具合修正とかは自分で取り込む必要がある
不安定なほど機能追加や不具合修正を自動で取り入れられるが、意図しない変更や悪意のある変更を取り込むリスクがあがる
用途と提供元の信頼度などを考えて使うといいだろう
action を自作する場合、所定のルールに従っているリポジトリであれば、自動で検索して使わせることができる
特にどこかへの登録やホスティングは必要ない
必須ではないが推奨される README.md
のテンプレがあるので、それを使うといいだろう
yaml で shell を指定することで、直接 yaml に python コードを書くことが可能
この辺はローカルで python を実装してデバッグするなら shell からの .py
呼び出し、
ローカルの python のバージョンを合わせるのが面倒だったりリモートでだけ動けば良い軽い処理なら yaml に直接
みたいに使い分けると良さそう
トリガーはかなり細かい制御ができる
特定のパスに変更があった場合に限ったりできるし、ワイルドカードも使用可能
docs/*.md
の変更があった場合に限ったりできる
キャッシュを使うことができるので違うビルドと共有することができる
大きな npm install
とかを必要とするときはうまく使いたい
アーティファクトという成果物が作れる
ただしこれはデプロイ処理とかを指すのではなく、ブラウザでの action 結果画面から DL できる成果物となる
( つまり upload 先は GitHub ということ )
ただしこれは 90 日で破棄される
ビルドレポートとかプロファイリング結果とかなら大いに役立ちそうだが、マニュアルや API 仕様書などをアーティファクトとするのは不適切だろう
トリガー部分を外部からキックするエンドポイントにすることが可能
そうすると curl
で普通の github api を使ってキックできるようになる
Azure ではなく自分で用意したホスティングサーバで動かすこともできる
値段や性能や提供される環境の点で融通がきくが、github にマネージされないことと構築コストを考える必要がある
以上
個人的には ci/cd とかは当然として、実装フェーズになったら次のような用途で利用したいと思っている
- リポジトリで管理しているドキュメントをかき集めて見やすくする
-
*.md
をかき集める- ADR やコーディングルールや保守用ドキュメントなど
-
*.puml
を.png
化する- クラス図など
- ドキュメント生成を行う
- API 仕様書とかを生成する
- ER 図などを生成する
- Javadoc とかを生成する
- BDD 系テストを実行してレポートを生成する
- index.html を生成してリンク集をぶち込む
- gh-pages とか S3 にホスティングする
-
とか
あとは略記だがこんなあたりを仕込んでいきたい
- プロファイリングをアーティファクトとして閲覧する
- テスト結果をアーティファクトとして閲覧する
- 何かスプリントレビューに使えるような結果や生成物をアーティファクトで運用できないか
- 開発の健康状態の可視化
- PR の頻度やコメント率やマージ率
- PR が出てからマージされるまでの時間
- PR がマージされてからリリースされるまでの時間
- 放置されている issue のリマインド
- コメントがしばらくついてないとか
これくらいで、必要になったら十分自分で調整できるだろう
読むだけなら 1h もあれば十分だった
全体像をざっと把握できて大変良かった
試すなら +3h くらいかな