投げたPRはこちら
動機
とある事情でCI用途のパーソナルアクセストークンを撲滅したかった件の一環です。
解説
GitHub Actionsはジョブ実行時に自動でアクセストークンをセットしてくれて便利なんですが、API実行の許可は付与されていても git push に対する許可が与えられていませんでした。
具体的には下記がGitHub Actionsだとエラーになります。
そこでシステムの git で git commit と git push してる部分をAPIで置き換えた感じです。
circleci-bundle-update-prをGitHub Actionsで動かす方法
https://github.com/masutaka/circleci-bundle-update-pr#run-on-github-actions にも書いたようにGitHub Actionsの変数をCircleCIの変数でexportしなおしてあげるだけでGitHub Actionsで動くようになります。
実際にGitHub Actionsで動かした図がこちら
補足
執筆時点では
steps: - name: Set up Ruby uses: actions/setup-ruby@v1 with: ruby-version: v2.6.4
のように書いてもRuby 2.6.4をインストールできないため *1、 Gemfile で ruby "2.6.4" を書いているとかでどうしてもRuby 2.6.4を使いたい場合には
container: image: ruby:2.6.4
のようにDockerイメージを使うのがいいと思います。
circleci-bundle-update-prをGitHub Actionsで動かすメリット
- パーソナルアクセストークンの発行が不要になる
- CircleCIがorg単位での並列数に対してGitHub Actionsがリポジトリ単位での並列数なので、複数リポジトリで同時にジョブが実行されても詰まらない
circleci-bundle-update-prをGitHub Actionsで動かすデメリット
- GitHub Actionsにはキャッシュがないため、毎回フルでbundle installが実行されて遅い
- schedulerで定期的に動かすジョブなので少々遅いのは個人的には許容できる
- Betaなのでキャッシュがないと割り切っています（楽観）
余談1
gitlabci-bundle-update-mr で同じ方針でやったので余裕かと思ってたら、GitLabだとAPI 1回で済んだことがGitHubだとAPI 7回もかかって意外に手ごわかった、、、
- GitLab版: https://gitlab.com/sue445/gitlabci-bundle-update-mr/blob/v0.3.0/lib/gitlabci/bundle/update/mr/client.rb#L63-80
- GitHub版: https://github.com/masutaka/circleci-bundle-update-pr/blob/v1.17.0/lib/circleci/bundle/update/pr.rb#L106-L145
余談2
dependabotでええやんっていうのもごもっともなんですが、dependabotだと1 bundle update 1 PRになっている関係でPRが大量にきた時にCIが詰まるという問題があるので個人的には circleci-bundle-update-pr くらいの粒度が好きです。
あと、circleci-bundle-update-prだと下記のようにすることで週替りでbundle update当番を割り当てることができるんですが、dependabotだと同じことができない（assigneesが固定値しか渡せない）ためcircleci-bundle-update-prを使い続けてるというのもあります。
circleci-bundle-update-pr --assignees $(ruby -rtime -e 'a=%w[foo bar baz]; print a[Time.now.to_date.cweek% a.size]')
