GitHub の Deployments API を使ったデプロイのワークフローのイメージ

github

GitHub の Deployments API を使うと Web アプリケーションのリリース (デプロイ) に関わるワークフローをより便利にできそうだったので、試したことを記録する。

Deployments API でできること

すべてドキュメントに書いてあるが、かいつまむと:

  • 「デプロイ」を表現するイベントを作ることができる
  • 進捗 (e.g. 成功、実行中, etc.) を表現できる
  • (「デプロイ」を表現するイベントに紐付くメタデータ (e.g. 説明、payload) を作ることができる)

……という具合である。

つまり GitHub の API は具体的なデプロイのタスクについて責務を負うことはなく、「デプロイ」というイベントをリポジトリにアーカイブしそれらを通知する責務のみを負う、ということになる。Webhook のひとつと言い換えてもよい。

Deployments API と Commit Status API の context について

Deployments を作成する時に required_contexts というパラメータを渡すことができる。

ドキュメントには:

By default, commit statuses for every submitted context must be in a ‘success’ state. The required_contexts parameter allows you to specify a subset of contexts that must be “success”, or to specify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do not require any contexts or create any commit statuses, the deployment will always succeed.

……とある。

つまり、これから作成する Deployments が参照しているコミットの Status について、required_contexts で指定して context に対応する Status が成功した状態であることを求める、ということになる。

context については、Commit Status API において:

Statuses can include a context to indicate what service is providing that status. For example, you may have your continuous integration service push statuses with a context of ci, and a security audit tool push statuses with a context of security. You can then use the combined status endpoint to retrieve the whole status for a commit.

……とある。

たとえば Jenkins でのビルド状態を表す ci/jenkins であるとか、ステージング環境におけるチェックを表す check/staging などが、考えられる。

実際には、これら2つの API を組み合わせて、たとえば次のようなワークフローが考えられるかもしれない:

  • CI でビルドが成功すると Commit Status API で ci/jenkins が成功したとラベル付けされる
  • 手動でのステージング環境におけるチェックが済んだら「hubot: staging is ok」と発言すると Hubot が Commit Status API で check/staging が成功したとラベル付けされる

実際のイメージ

staging でのチェックが進行中で、大安を待つことは既に成功している、ということが伺える。

staging のチェックも完了した。"Caution to Merge" も消えている。

まとめ