VSCode May 2022で紹介されていたDev Container in CIについて調べてみた
VSCode May 2022 (version 1.68)にDevelopment Container Specification関連の発表があった。
その中に、Dev Container in CIという項目があり、それについて調べてみた。
Dev Container in CI
GitHub ActionとAzure DevOpsでdevcontainer.jsonで定義されたDevelopment Containerを使えるようになったようだ。
Development Containerについては、以下の記事を参照のこと。
以降、本記事ではGitHub ActionでのDevelopment Containerの利用について記載する。
GitHub ActionでDevelopment Container使用に関するドキュメントは以下で確認できる。
上記を見ると、devcontainers/ci@v0.2というActionsを用いていることがわかる。ActionsについてはGitHub Docs > GitHub Actions > Learn GitHub Actions > Actionsを参照のこと。
また、devcontainers/ciのソースは以下。
devcontainers/ciのGitHub Actionのドキュメントを参考に、以下のリポジトリで実際にDevelopement ContainerでのCI(と言っても、go testしているだけだが)をやってみた。
基本的にはビルドしたDocker Imageを保存するDocker Registryが必要で今回はこのリポジトリのGitHub Container Registryを使用した。
ただし、これを使用するためにはリポジトリをpublicにしておく必要がある。
リポジトリ内の.devcontainer/devcontainer.jsonは以下のみで、ローカル開発で使用したDev container featuresの設定しかない。
workflow上だとgo testは以下で実行されていた。
所感
以前より、Dev container featuresを用いることにより自力でいちいち必要な設定を調べず、Dockerfileに設定を入れ込まなくてもローカル開発を始めることができるようになっていた。
これと同じような感覚で、CIの実行環境として改めて何か準備することなく、CIを始められる選択肢ができたのは良いことのように思う。
これを使えばCIで実行される環境をローカル開発で使用できるので、何度もリポジトリにプッシュしてCIを動かすみたいな試行錯誤を減らすことができるのではないでしょうか。
CIで使う際は、それを念頭においた設定をする必要があり、ローカル開発環境にも多少影響があるのではとも考えた。例えば、今回の設定でDev container featuresで導入したgolangのバージョンにはlatestを指定したが、CI上でバージョンを固定にしないのは好ましくないように思う。
また、明示的にDockerfileに設定内容を記載できていないと、作成したDocker Imageがブラックボックスになりやすいかもしれない。
Discussion