Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Kenta Kase
October 16, 2019

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

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

Kenta Kase

October 16, 2019
Tweet

More Decks by Kenta Kase

Other Decks in Programming

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. 6
    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/[email protected]
    #
    コンテナ上で実⾏される
    # 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/[email protected]
    - name: "ruby version"
    run: ruby --version

    View Slide

  25. 25
    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