CircleCIでgit-pr-releaseする
git-pr-releaseそのものの説明に関してはninjinkunの以下のエントリを参照ください。
さて、現職に入社したら、git-pr-releaseが使われていたのですが、リリース担当者が手元で実行するフローになっていました。しかし、git-pr-releaseの本場であり発祥の地でもある、はてな社では、git-pr-releaseはCIに作らせるものであったので、それに倣って、こちらも現職で利用しているCircleCIに作らせるようにしてみた。
手順
.git-pr-releaseをrepositoryに配置するGIT_PR_RELEASE_TOKENをCircleCIに登録する.circleci/config.ymlにjobを設定する
おまけ
- machine accountを作るといいよ
- Triage(トリアージ)権限が便利
1. .git-pr-releaseをrepositoryに配置する
すでにgit-pr-releaseをお使いの場合は、既に配置されているかも知れませんが、repository rootに以下のような.git-pr-releaseファイルを配置してコミットもしておく。
[pr-release "branch"]
production = master
staging = develop
[pr-release]
labels = pr-release
pr-release.labels でラベルの設定もできるのでこれも後でリリース履歴のリストアップするときなどに便利です。設定を~/.gitconfigや.git/configに登録しておく手もありますが、ちゃんとrepositoryに置いておくとプロジェクト共通の設定になるので何にせよ良いです。
2. GIT_PR_RELEASE_TOKEN をCircleCIに登録する
GitHub上でpersonal access tokenを発行する。その際、scopeの選択のときにrepoにチェックを入れておく。
そこで作られたtokenをCircleCIのプロジェクトの環境変数設定で GIT_PR_RELEASE_TOKEN という名前で登録しておく。
ここで個人のpersonal access tokenを使うのが嫌な場合は、後述のmachine accountを活用すると良い。
3. .circleci/config.yml にjobを設定する
CircleCIの設定に例えば以下のようにjobを設定する。ここでは"pr-release"という名前で、jobを設定している。たった3ステップの簡単なjobである。
version: 2.1
jobs:
build:
...(略)...
pr-release:
docker:
- image: circleci/ruby
steps:
- checkout
- run: gem install -N git-pr-release
- run: git-pr-release --no-fetch
workflows:
version: 2.1
works:
jobs:
- build
- pr-release:
filters:
branches:
only: develop
workflowのfilters設定で、developでしか動かないように設定しているのもポイントで、これで、developが進んだときだけgit-pr-releaseが再実行されることになる。そして、git-pr-releaseは再実行してもいい感じに既存のpull requestをアップデートしてくれるのです。
ということでこれだけで、developにfeatureブランチをマージしていけばCircleCIが自動的にpr-releaseを生やしてくれるようになりました。開発者の手元にgit-pr-releaseをインストールする必要もなくなりました。めでたしめでたし。
おまけ: machine accountとTriage権限の話
個人のtokenを使うの怖いし、退職リスク等もあるので、アクセスできるrepositoryや権限を絞ったユーザーを自動化のためにオーガニゼーションに一つ作るとよいでしょう。
これは、GitHubの利用規約に、machine accountという名前で定義されています。自動化のためのアカウントを1フリーユーザー辺り1つ作ってもよく、これを複数人でメンテしても良いとされています。
A machine account is an Account set up by an individual human who accepts the Terms on behalf of the Account, provides a valid email address, and is responsible for its actions. A machine account is used exclusively for performing automated tasks. Multiple users may direct the actions of a machine account, but the owner of the Account is ultimately responsible for the machine's actions. You may maintain no more than one free machine account in addition to your free User Account.
Triage(トリアージ)権限
machine accountには必要以上の権限を与えるべきではなく、一般的にはrepositoryのRead権限のみを与えることになるでしょう。
しかし今回の、git-pr-releaseを実行させる場合、pull requestを作成しそれにラベルを付与します。しかし、ラベルの付与はRead権限のみではできません。
ここで、最近ベータで追加されたTriage権限が有用です。これはRead権限に加えて、issueやpull requestの操作が可能になっているものです。
ref. https://help.github.com/en/articles/repository-permission-levels-for-an-organization
とう言うことで、今回の場合、machineアカウントに対象repositoryへのTriage権限を付与すれば万事解決です。
ニッチな権限でありますが、このようにうまく嵌るところが見つかると面白いですね。
ちなみに、machine accountは複数のprivate repositoryにアクセスが必要なCI/CDを構築する際にも効果を発揮するのでその辺りはまた今度。