どたばたしながらCI/CD整備した話
CI/CD
継続的インテグレーション/デプロイのこと｡
コードを本番環境での動作以外で保証するために､例えばテスト実行をしたり､リントツールにかけたり､マルチプラットフォームなアプリであればそれぞれ別の環境で仮実行したりする(インテグレーション)
また実際に動かす場所にコードの実行可能ファイルやパッケージを共有して動作させること(デプロイ)
これら2つを特定の条件で自動実行すること｡だいたいそんな感じだと思います｡
まぁ色々メリットはありますが､自動でチェックしてくれるのがかっこいいと思うから使ってます｡
今回はGitHub ActionsでまたCI/CDを整備したのでいい加減メモを作って備忘録にします｡公式のドキュメントなんか読みづらいんですよね
GitHub Actions
CI/CDツールの一つ(他にもCircleCIやJenkins､TraisCIなどがある)
GitHub上で実行できるのが強みで､コード管理､特にプルリクエスト(確定バージョンを残すことが多いmain/masterブランチにマージする前)にてGitHub上でCIを走らせることができるので､便利｡学生ライセンスであれば無料で使える｡
Actionsを使ってみよう
-
適当なリポジトリを新規作成する｡(名前は何でも良い)
-
｢Actions｣タブでサジェストされたものを使ってみる
-
基本的な文法はこれで学べる
-
コミットしたあとに｢Actions｣>｢CI｣を見るとなにか走っている
-
走っている(た)ジョブが表示される
-
｢build｣を見るとこんな感じ(画像は適宜展開している)
simple workflowのコード
ワークフローファイルはYAML[1] (拡張子はyaml/yml)によって書かれており､記述はシンプルにできる｡
基本的にはWhen(いつこのワークフローを起こすのか)とWhat(何をこのワークフローでやるのか)を記述する｡それぞれonとjobsに該当する｡
大体いるやつ
on ‐ ワークフローのトリガ
よく使われるケースとして､PRの差分がただしいかどうか最低限の担保をするために､リンターやテストを走らせるケースがあります｡こうした場合､この｢mainへのPR｣というイベントをトリガとしてワークフローを自動実行することが必要になります｡
on:
pull_request:
branches : "main"
onに対してイベントを列挙することで､ワークフローの発火タイミングを設定できます｡
他にもGitの各種コマンドや､もちろんリポジトリ外のものをイベントとして扱えたりもします｡(このあたりは詳しくは解説できないです)
jobs - やることリスト
ワークフローの本体｡Whatの部分｡jobを次のインデントで定義する｡その時､ジョブの名前は任意｡
runs-on ‐ 走らせるマシンを定義
まぁ大体ubuntu-latestを私は使っていますが､例えば挙動を複数のOSで確認したい場合に指定したりします｡
steps ‐ ジョブのやることリスト
name - ステップに名前をつける
runで走らせるコマンドが長かったり分かりづらい場合に別名をつける
run - コマンド実行
シェルコマンドを実行する
変数を使う
変数を使いたい場合は${{ hogehoge.HOGEHOGE }}
uses ‐ 他の人のワークフローを使う
他のファイルのワークフローや公開されているワークフローをつかうことができる｡
公開されいるものを使う場合は､uses: hoge-name/hoge-jobs@v~みたいな書き方
小技
needs ‐ 他のジョブの完了に依存する
timeout-minutes - タイムアウトの指定
ひとまず色々まとめてみましたが､相変わらず毎回初回のジョブは失敗するのでダッシュボードでお祈りしてます｡早く慣れたいですね｡あとは自分が使ってないだけで､並列実行のmatrixや､ここでは紹介していませんがreusable-workflowなどがあります｡
Actionsを公開しているものはGitHubにコードが上がっているので､それを参考にしてみるのもいいかもしれません｡
追記
そういえば自分で作ったCI/CDの話を全然していませんでした｡
今回整備したのは､Rustでfmt clippy testし､問題なければShuttleにデプロイするというものです｡
今回はRustのRepoのCI整備なので､デフォルトでcargoのもつ機能を使うだけなのでわりと簡単だと思うのですが､JS/TS系はどうにも選択肢が多すぎる気はこうしてCI整備していると思いますね(package.jsonをきちんと書きなさいという話だと思うんですが)
上記で紹介していない部分は､workflow_callですね｡ci.yaml:call-deployでファイルを指定してワークフローを発火､deploy.yamlはイベントトリガとしてworkflow_callを指定しているので､それに基づいて実行される､という形です｡
-
YAML(YAML Ain't Markup Language)のこと｡書きやすいらしい｡設定記述用の言語としてよく使われている｡公式では
yaml推奨とは言っているもののどちらでもあまり変わらないみたい? ↩︎
Discussion