GitHub Actionsが他のCIサービスと比較してできることできないこと

GitHub Actions Meetup Tokyo β
https://gaugt.connpass.com/event/147220/

Transcript

1. GitHub Actionsが他のCIサービスと⽐較してできることできないこと
   GitHub Actions Meetup Tokyo β (10/16)
   @Kesin11
   

   View Slide

2. ⾃⼰紹介
   @Kesin11 (GitHub/Twitter)
   DeNA SWETグループ
   開発効率向上を⽬的として、テストやCI/CDの調査・事業
   部サポートなど
   （おそらく普通よりは）CIマニアの気がある
   わりと早期に運良くyaml版を使えるようになっていたので記
   事を書いていました
   新GitHub ActionsはCIに使えるか
   2
   2
   

   View Slide

3. はじめに
   この発表はCI/CDの中級者を対象に考えています
   他のCIサービスは⼀通り触ったことがある前提
   CircleCI, TravisCI, Google Cloud Build
   もし間違ったことを⾔っていたらTwitterや懇親会のときに教
   えてもらえると嬉しいです
   GitHub Actionsはまだβなので正式リリース時には状況が変
   わってる可能性が⾼いです
   3
   3
   

   View Slide

4. ビルドキャッシュとアーティファクト
   

   View Slide

5. GitHub Actionsの現在
   ビルドキャッシュ: 不可能
   node_modules(npm), vendor(bundler)など
   依存モジュールは毎回ダウンロード&ビルドやりなおし
   アーティファクト保存: 可能
   ビルドしたバイナリなどをダウンロードできるようにする
   5
   5
   

   View Slide

6. View Slide

7. CircleCIの機能との対応表
   CircleCI GitHub Actions
   save_cache -
   restore_cache -
   store_artifact actions/upload-artifact
   persist_to_workspace actions/upload-artifact
   attach_workspace actions/download-artifact
   7
   7
   

   View Slide

8. キャッシュの種類について
   前のworkflow実⾏から引き継げるか、今のworkflow内だけ
   かが⼤きな違い
   GitHub Actionsでは
   前のworkflowのキャッシュやアーティファクトは使えない
   アーティファクトとして回収すれば同じworkflow実⾏内で
   あればjob間でやりとりできる
   8
   8
   

   View Slide

9. ビルドキャッシュが使えないことは問題か？
   ビルドに時間がかからないライブラリ系なら問題なさそう
   jobが多くても並列数で殴ればトータル時間は変わらない
   依存モジュールが多い、ネイティブビルドが多い場合はネッ
   クになる
   iOS、Androidアプリなどは厳しそう
   9
   9
   

   View Slide

10. マトリックスビルド
    

    View Slide

11. マトリックスビルド
    CIとしてのGitHub Actionsの⽬⽟
    今までTravisCIがOSS界隈のデファクトであった⼤きな理由
    のはず
    11
    11
    

    View Slide

12. TravisCI
    12
    12
    

    View Slide

13. GitHub Actions
    13
    13
    

    View Slide

14. TravisCIとの違い
    ⾔語バージョンを選択するデファクトなツールが使えない
    rvm, nvmなど
    actions/setup-xxxx
    js/tsでそれぞれの⾔語ごとに実装されている
    nodeの場合はバイナリをダウンロード、PATH通して、
    undocumentなキャッシュ領域に保存していた
    14
    14
    

    View Slide

15. 問題点
    バージョン指定の選択が独⾃実装
    latestとかstableとかltsのようなエイリアスが使えない
    ⾞輪の再発明では？
    とはいえ、⼤抵の場合はそんなに問題ではなさそう
    setup-xxxxが存在していない⾔語はバージョン切り替えられ
    なさそう
    15
    15
    

    View Slide

16. 実⾏環境について
    

    View Slide

17. VMとコンテナ
    今どきのCIサービスはVMとコンテナが混在している
    CircleCI
    基本はコンテナ。 machine: true
    やmacの場合はVM
    TravisCI
    基本はVM
    Cloud Build
    全部コンテナ(ちょっと特殊)
    GitHub Actions
    基本はVM。Linuxの場合は設定次第でコンテナにもできる 17
    17
    

    View Slide

18. stepごとの実⾏環境
    CIサービスによってはjob単位ではなくて、step単位で実⾏環境を変えられる
    CircleCI
    基本的にはできない。remote dockerを有効化すれば
    docker runで実質可能？
    Cloud Build
    元々step毎に必ずコンテナを指定させるスタイル
    GitHub Actions
    併⽤されるのが基本
    18
    18
    

    View Slide

19. GitHub Actionsの実⾏環境
    jobs:
    job:
    runs-on: ubuntu-latest
    steps:
    # VM
    上で実⾏される
    - run: env
    # VM
    かコンテナかは外部のaction
    の種類に依存する
    - uses: actions/checkout@v1
    #
    コンテナ上で実⾏される
    # with.args
    で任意のコマンドを実⾏できる
    - uses: docker://node:10
    with:
    args: echo "foo bar"
    

    View Slide

20. 「基本コンテナ上で実⾏」に切り替える
    job.container.imageで使うコンテナを指定
    つまり挙動として基本コンテナのCircleCIに近くなる
    jobs:
    job:
    runs-on: ubuntu-latest
    container:
    image: "node:12"
    steps:
    #
    コンテナ上で実⾏される
    - run: node --version
    

    View Slide

21. マトリックスビルドとコンテナ
    

    View Slide

22. お気づきでしょうか？
    22
    22
    

    View Slide

23. マトリックスビルド + containerとした場合にどうなる？
    23
    23
    

    View Slide

24. 試してみた
    jobs:
    job:
    strategy:
    matrix:
    container: ["ruby:2.4", "ruby:2.5", "ruby:2.6"]
    runs-on: ubuntu-latest
    container:
    image: ${{ matrix.container }}
    steps:
    - uses: actions/checkout@v1
    - name: "ruby version"
    run: ruby --version
    

    View Slide

25. View Slide

26. マトリックスビルド + container
    github.com/Kesin11/danger-textlint/pull/16
    マトリックスで指定したイメージ上でテストが実⾏でき
    る！！
    actions/setup-xxxxに頼る必要がない
    多分他のCIで同じことができるものはないので唯⼀無⼆
    各⾔語の公式イメージ上で実⾏できる安⼼感
    OSS⽤途としては最⾼では
    ただしLinux上での実⾏に限る
    26
    26
    

    View Slide

27. その他細かいこと1
    Slack通知
    サポート無し。⾃⼒でやる
    push, pull-req以外のwebhookトリガー
    可能。GitHub Actionsならでは
    新たなpushで溜まったキューのキャンセル
    CircleCIだとAuto-cancel redundant builds
    ない。正式版になって課⾦されるようになると困るかも
    rerunがworkflow単位
    TravisCIのようにマトリックスの⼀部だけrerunできない
    27
    27
    

    View Slide

28. その他細かいこと2
    Docker in Docker
    CircleCIのような特殊なことをせずとも可能
    job.container.imageで docker
    を指定して、 docker
    build
    などはそのまま動く
    docker buildのキャッシュ
    CircleCIのlayer cache、Cloud BuildのKanikoのような
    便利な仕組みはない
    同じくβのGitHub Package Resistoryと --cache-from
    を組み合わせるぐらい？
    28
    28
    

    View Slide

29. まとめ
    ビルドキャッシュは無い（少なくとも今は）
    マトリックスビルドは便利
    マトリックスビルド + containerは唯⼀無⼆
    まだβなので、より便利になると信じている
    ⾊々実験した記録のリポジトリ
    github.com/Kesin11/github_actions_matrix_js_sandbox
    29
    29
    Slide created by Marp(marp.app)
    Slide created by Marp(marp.app)
    

    View Slide