最近は、 Github Workflow を使うことが多くなってきたけど、まだまだ他の SaaS の CI の第一候補になりません.
検討する際に見落とすことがあるので、自分へのチェックシート代わりに この記事を書きました. 気がつくことがあれば常に更新していく様にします.
Docker の実行が遅い
最近、よく使うツールの一つに Docker がありますが、 Github Workflow ではまだまだ遅いらしいです.
自分は Circle CI をメインにしてたので、気がつかなかったのですが以下の記事に書いてあって、 github/super-linter が遅い理由はこれかもしれないと思いました.
特定の Job の Rerun が無い
CI で複雑なワークフローを構築して一部だけ失敗したら、再実行したい時は結構あります.
例えば、依存パッケージをダウンロードしてキャッシュを作っておき、分岐したタスクでそれらを利用するとかです.
Github Workflow は Workflow を丸ごと Rerun することは出来ますが、 その内の特定の Job の Rerun は出来ません. 時間で課金されるので長時間動くような Workflow だと致命的です.
コミュニティでも指摘されてますが、現在まで特に公式からの対応はありません.
Workflow を 分割してトリガーを駆使すれば似た様なことは出来ますが、メンテナンス性が下がるので避けたいところです.
ハードウェアリソースが限られている
マシンパワーが必要な場合 CircleCI は resource_class の指定で、ある程度は選択できます.
現状の GitHub Workflow では ハードウェア リソース が以下の要件で足りているか確認する.
Each virtual machine has the same hardware resources available.
- 2-core CPU
- 7 GB of RAM memory
- 14 GB of SSD disk space
自動キャンセルがない
コミットを新しく git-push したりすると、 Circle CI だと自動的に前回のワークフローが実行していた場合にキャンセルしてくれます.
GitHub Workflow ではキャンセルしてくれません. rokroskar/workflow-run-cleanup-action 等のアクションを使えば同様のことをしてくれます.
コミットメッセージに [ci skip]
を含めても CI はスキップしない.
Travis CI や Circle CI 等であれば、 [ci skip]
をコミットメッセージに含めれば自動的にCIの実行をスキップしてくれます.
Github Workflow で以下のように仕掛けておけば、似た感じに動いてくれます.
jobs:
prepare:
runs-on: ubuntu-latest
if: "! contains(github.event.head_commit.message, '[ci skip]')"
steps:
- run: echo "ci skip"
build:
runs-on: ubuntu-latest
needs: prepare