GitHub Actions Meetup Tokyo β https://gaugt.connpass.com/event/147220/
GitHub Actionsが他のCIサービスと⽐較してできることできないことGitHub Actions Meetup Tokyo β (10/16)@Kesin11
View Slide
⾃⼰紹介@Kesin11 (GitHub/Twitter)DeNA SWETグループ開発効率向上を⽬的として、テストやCI/CDの調査・事業部サポートなど(おそらく普通よりは)CIマニアの気があるわりと早期に運良くyaml版を使えるようになっていたので記事を書いていました新GitHub ActionsはCIに使えるか22
はじめにこの発表はCI/CDの中級者を対象に考えています他のCIサービスは⼀通り触ったことがある前提CircleCI, TravisCI, Google Cloud Buildもし間違ったことを⾔っていたらTwitterや懇親会のときに教えてもらえると嬉しいですGitHub Actionsはまだβなので正式リリース時には状況が変わってる可能性が⾼いです33
ビルドキャッシュとアーティファクト
GitHub Actionsの現在ビルドキャッシュ: 不可能node_modules(npm), vendor(bundler)など依存モジュールは毎回ダウンロード&ビルドやりなおしアーティファクト保存: 可能ビルドしたバイナリなどをダウンロードできるようにする55
66
CircleCIの機能との対応表CircleCI GitHub Actionssave_cache -restore_cache -store_artifact actions/upload-artifactpersist_to_workspace actions/upload-artifactattach_workspace actions/download-artifact77
キャッシュの種類について前のworkflow実⾏から引き継げるか、今のworkflow内だけかが⼤きな違いGitHub Actionsでは前のworkflowのキャッシュやアーティファクトは使えないアーティファクトとして回収すれば同じworkflow実⾏内であればjob間でやりとりできる88
ビルドキャッシュが使えないことは問題か?ビルドに時間がかからないライブラリ系なら問題なさそうjobが多くても並列数で殴ればトータル時間は変わらない依存モジュールが多い、ネイティブビルドが多い場合はネックになるiOS、Androidアプリなどは厳しそう99
マトリックスビルド
マトリックスビルドCIとしてのGitHub Actionsの⽬⽟今までTravisCIがOSS界隈のデファクトであった⼤きな理由のはず1111
TravisCI1212
GitHub Actions1313
TravisCIとの違い⾔語バージョンを選択するデファクトなツールが使えないrvm, nvmなどactions/setup-xxxxjs/tsでそれぞれの⾔語ごとに実装されているnodeの場合はバイナリをダウンロード、PATH通して、undocumentなキャッシュ領域に保存していた1414
問題点バージョン指定の選択が独⾃実装latestとかstableとかltsのようなエイリアスが使えない⾞輪の再発明では?とはいえ、⼤抵の場合はそんなに問題ではなさそうsetup-xxxxが存在していない⾔語はバージョン切り替えられなさそう1515
実⾏環境について
VMとコンテナ今どきのCIサービスはVMとコンテナが混在しているCircleCI基本はコンテナ。 machine: trueやmacの場合はVMTravisCI基本はVMCloud Build全部コンテナ(ちょっと特殊)GitHub Actions基本はVM。Linuxの場合は設定次第でコンテナにもできる 1717
stepごとの実⾏環境CIサービスによってはjob単位ではなくて、step単位で実⾏環境を変えられるCircleCI基本的にはできない。remote dockerを有効化すればdocker runで実質可能?Cloud Build元々step毎に必ずコンテナを指定させるスタイルGitHub Actions併⽤されるのが基本1818
GitHub Actionsの実⾏環境jobs:job:runs-on: ubuntu-lateststeps:# VM上で実⾏される- run: env# VMかコンテナかは外部のactionの種類に依存する- uses: actions/[email protected]#コンテナ上で実⾏される# with.argsで任意のコマンドを実⾏できる- uses: docker://node:10with:args: echo "foo bar"
「基本コンテナ上で実⾏」に切り替えるjob.container.imageで使うコンテナを指定つまり挙動として基本コンテナのCircleCIに近くなるjobs:job:runs-on: ubuntu-latestcontainer:image: "node:12"steps:#コンテナ上で実⾏される- run: node --version
マトリックスビルドとコンテナ
お気づきでしょうか?2222
マトリックスビルド + containerとした場合にどうなる?2323
試してみたjobs:job:strategy:matrix:container: ["ruby:2.4", "ruby:2.5", "ruby:2.6"]runs-on: ubuntu-latestcontainer:image: ${{ matrix.container }}steps:- uses: actions/[email protected]- name: "ruby version"run: ruby --version
2525
マトリックスビルド + containergithub.com/Kesin11/danger-textlint/pull/16マトリックスで指定したイメージ上でテストが実⾏できる!!actions/setup-xxxxに頼る必要がない多分他のCIで同じことができるものはないので唯⼀無⼆各⾔語の公式イメージ上で実⾏できる安⼼感OSS⽤途としては最⾼ではただしLinux上での実⾏に限る2626
その他細かいこと1Slack通知サポート無し。⾃⼒でやるpush, pull-req以外のwebhookトリガー可能。GitHub Actionsならでは新たなpushで溜まったキューのキャンセルCircleCIだとAuto-cancel redundant buildsない。正式版になって課⾦されるようになると困るかもrerunがworkflow単位TravisCIのようにマトリックスの⼀部だけrerunできない2727
その他細かいこと2Docker in DockerCircleCIのような特殊なことをせずとも可能job.container.imageで dockerを指定して、 dockerbuildなどはそのまま動くdocker buildのキャッシュCircleCIのlayer cache、Cloud BuildのKanikoのような便利な仕組みはない同じくβのGitHub Package Resistoryと --cache-fromを組み合わせるぐらい?2828
まとめビルドキャッシュは無い(少なくとも今は)マトリックスビルドは便利マトリックスビルド + containerは唯⼀無⼆まだβなので、より便利になると信じている⾊々実験した記録のリポジトリgithub.com/Kesin11/github_actions_matrix_js_sandbox2929Slide created by Marp(marp.app)Slide created by Marp(marp.app)