この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
Actionsのworkflowを用途別に準備したところ、重複する部分が多くなり、個別メンテナンスの手間をなくすために共通化を試みました。
Stepの共有化に最適な仕組みとして Composite Run Steps もありますが、公開リポジトリ前提となるため今回は要件上利用できません。
重複する箇所の多くはcurlによるDeployment API呼び出しが占めていたため、シェルスクリプト化した上で各workflowからの参照を試みました。が、Deployment APIを呼び出すActionが既にあることと、利用しているパラメータをActionに渡すだけで代替可能であるため、手っ取り早くActionへの差し替えを行いました。
今回はrunによるcurlベースでの呼び出しを行ったコードとActionへ置き換えを行った後の比較エントリーとなります。
置き換えるコードについて
置き換え前のコードについては以下の過去エントリー内にでているものとなります。
当時は動作把握のために敢えてActionを使いませんでしたが、今回は十分に挙動を理解した上での置き換えとなります。
置き換えるActionについて
以下2つのActionを用います。
Deployment Status 用のActionにはDeployment Data用Actionを実行した後に払い出されるidが必要になります。
Deployment Dataの置き換え
置き換え前後で並べてみます。URL等は環境変数を用いることでActionパッケージ内で汎用化され、指定する必要はなくなっています。
Deployment Data 置き換え前
API側で初期設定値というものはないため、個別に指定が必要です。
- name: Create deployment
run: |
create_deployment_request_url=${{ env.DEPLOYMENT_API_BASE }}
deployment_data=$(curl -X POST -v \
-d '{
"ref": "${{ env.branch }}",
"production_environment": false,
"environment": "${{ env.ENVIRONMENT }}"
}' \
-H "${{ env.HEAD }}" -H "Content-Type: application/json" -H 'Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' \
$create_deployment_request_url)
echo "deployment_id=$(echo $deployment_data | jq '.id')" >>; $GITHUB_ENV
Deployment Data 置き換え後
header指定はAction内に含まれており、パラメータも幾つかはActionの初期指定と同一となるため、必要最低限のみとなっています。また、このステップだけでは分かりませんが output にて deployment_id が出力されています。
- uses: chrnorm/deployment-action@releases/v1
name: Create GitHub deploymen
id: deploymen
with
token: "${{ github.token }}
environment: production
置き換え後のパラメータ
Actionのインストールページにはenvironmentに関する記載がないのですが、ソースコード上では指定を受け付けています。
name | description | |
---|---|---|
Deploymentの初期ステータス。一つ以上の文字列にすべきです。 | x | |
GitHub token | o | |
URLを指定します。デプロイされたアプリに関するURLにすべきです。指定がなければchecksのurlが代入されます。 | x | |
環境に関する記述を指定します | x | |
(初期はfalse) true指定でActionが実行されると、ブランチがリポジトリの規定ブランチにオートマージされます。詳細はGitHub Deployment APIのドキュメントに記載があります。 | o | |
デプロイする対象です。ブランチ、タグ、ハッシュが指定できます。 | x | |
(初期はproduction)環境を指定します。 | x |
Deployment Statusの置き換え
置き換え前後で並べてみます。同じくURL等は環境変数を用いることでActionパッケージ内で汎用化され、指定する必要はなくなっています。
Deployment Status 置き換え前
API側で初期設定値というものはないため、個別に指定が必要です。
- name: Create deployment status
run: |
create_deployment_status_request_url=${{ env.DEPLOYMENT_API_BASE }}/$(echo $deployment_data | jq '.id')/statuses
deployment_status_data=$(curl -X POST -v \
-d '{
"description": "Start deploy",
"state": "in_progress",
"log_url": "${{ env.log_url }}",
"environment": "${{ env.ENVIRONMENT }}"
}' \
-H "${{ env.DEPLOYMENT_STATUS_HEAD }}" -H "Content-Type: application/json" -H 'Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' \
$create_deployment_status_request_url)
Deployment Data 置き換え後
header指定はAction内に含まれており、パラメータも幾つかはActionの初期指定と同一となるため、必要最低限のみとなっています。Deployment Dataのoutputにて出力されるdeployment_idが必須です。
- name: Update deployment status (in_progress)
uses: chrnorm/deployment-status@releases/v1
with:
token: "${{ github.token }}"
state: "in_progress"
description: "Start deploy"
deployment_id: ${{ steps.deployment.outputs.deployment_id }}
置き換え後のパラメータ
stateについては厳密なルール付がなく、successとfailure、処理前のqueuedと処理中にはin_progressあたりを使うと良いかもしれません。
name | description | |
---|---|---|
Deploymentのステータスを指定します。指定可能なのは以下のいずれかです。
|
o | |
GitHub token | o | |
デプロイされたアプリのURLを入れます。 | x | |
Deploymentに関する記述を入れます。 | x | |
環境へアクセスするためのURLを指定します。 | x | |
アップデートするDeploymentIDを指定します。 | o |
置き換えた後の動作の違い
全く同一です。なにか違いがでるのかなーと思いましたが、思いの外全く同じでした。
あとがき
workflowはコピペした後に一部を変えることで用途に応じた使い方ができます。ただし、それぞれ自前でAPIを実行している場合にはworkflow毎に自力で変更点への追従が必須となります。
Actionを使った場合も公開リポジトリ側での追従を待つ必要がありますが、利用者によるIssueという形での提案も可能です。属人化を減らせるという大きなメリットもあります。
APIの動作について把握ができたなら、自前での呼び出しからActionへ切り替えて少し楽をするのもありではないかと思います。