[GitHub Actions]Workflow上のDeployment APIの呼び出しをcurlからActionベースに切り替えてみた

はじめに

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	require
initial_status	Deploymentの初期ステータス。一つ以上の文字列にすべきです。	x
token	GitHub token	o
target_url	URLを指定します。デプロイされたアプリに関するURLにすべきです。指定がなければchecksのurlが代入されます。	x
description	環境に関する記述を指定します	x
auto_merge	(初期はfalse) true指定でActionが実行されると、ブランチがリポジトリの規定ブランチにオートマージされます。詳細はGitHub Deployment APIのドキュメントに記載があります。	o
ref	デプロイする対象です。ブランチ、タグ、ハッシュが指定できます。	x
environment	(初期は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	require
state	Deploymentのステータスを指定します。指定可能なのは以下のいずれかです。 "error" "failure" "inactive" "in_progress" "queued" "pending" "success"	o
token	GitHub token	o
target_url	デプロイされたアプリのURLを入れます。	x
description	Deploymentに関する記述を入れます。	x
environment_url	環境へアクセスするためのURLを指定します。	x
deployment_id	アップデートするDeploymentIDを指定します。	o

置き換えた後の動作の違い

全く同一です。なにか違いがでるのかなーと思いましたが、思いの外全く同じでした。

あとがき

workflowはコピペした後に一部を変えることで用途に応じた使い方ができます。ただし、それぞれ自前でAPIを実行している場合にはworkflow毎に自力で変更点への追従が必須となります。

Actionを使った場合も公開リポジトリ側での追従を待つ必要がありますが、利用者によるIssueという形での提案も可能です。属人化を減らせるという大きなメリットもあります。

APIの動作について把握ができたなら、自前での呼び出しからActionへ切り替えて少し楽をするのもありではないかと思います。