🤚

GitHub Actionsの手動実行パラメータのUI改善について速報で解説する

2021/11/14に公開

11/10に突如素晴らしいアップデートが来たので、興奮冷めやらぬうちに公式よりちょっとだけ詳しい解説を書きます。

GitHub Actionsは素晴らしいCI/CDサービスであり、特にpush, pull-request, その他あらゆるGitHub上の行動をトリガーにしてワークフローを起動させる設定を簡単に書くことができます。しかし、手動でワークフローを起動させる機能の追加は他のトリガーに比べて後発でしたし、パラメータを入力するための機能やUIが少々貧弱と言わざるを得ないものでした。

一方、古より存在するJenkinsはpush, pull-requestなどの自動トリガーを設定するのは難易度が高かった^[1]反面、手動でジョブを起動する機能やUIは充実していました。基本の自由テキスト以外に、プルダウンによる選択、booleanのチェックボックス、Jenkinsに登録したシークレットからの選択などデフォルトでも豊富な入力方法が存在していました。^[2]

手動で実行したいケースの代表格としてはデプロイ作業があげられるかと思います。最近ではCIOpsやGitOpsと呼ばれているように、特定のブランチやtagをpushしたときに自動デプロイが行われるようにCDを組んでいる方も多いかと思います。

ですが、デプロイ作業に限らず何かしらの事情によってgitに依存せずに手動で実行できた方が便利というケースもあったのではないでしょうか？そのような場合に登場する選択肢は・・・そうJenkinsでした 😇

しかし、それも今日までです。GitHub Actionsの workflow_dispatch のinput機能が拡張され、手動でワークフローを実行するときのUIも改善されました！

手動Deployを模したワークフローのサンプル

name: Manual Deploy

on:
  workflow_dispatch:
    inputs:
      target:
        type: choice
        description: Deploy target
        options: 
        - dev1
        - dev2
        - prod
      message:
        required: true
        default: "Write some messsage here"
      dryrun:
        type: boolean
        description: Is dryrun?
        default: true
      environment:
        type: environment

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ github.event.inputs.environment }}

    steps:
    - name: Show inputs
      run: |
        echo "target: ${{ github.event.inputs.target }}"
        echo "message: ${{ github.event.inputs.message }}"
        echo "dryrun: ${{ github.event.inputs.dryrun }}"
    - name: Deploy (use environemt secrets)
      run: |
        echo "Deploy target server: ${{ secrets.ENV_SERVER }}"

このワークフローを手動で実行するときのUIはこのようになります。

まず拡張されたinputsについての基本的な部分については冒頭に貼ったこちらのchangelogのブログを見てください。ここからはGithubの記事より少しだけ深い説明をしていきます。

デフォルト値の設定

default にデフォルト値を入力しておくことが可能です。booleanの場合についてはドキュメントにも書いていないように見えましたが、試してみたところ true にするとチェックボックスが最初からチェックされた状態になっていたので問題なく使えるようです。

environmentの利用

（事前知識）environmentについて

environment自体が比較的新しい機能なので知らない方も多いかと思います。特に個人のorgの場合はpublicなリポジトリでないとenvironmentの機能自体が使えなかったりします。

environmentにはいくつか機能があるのですが、特に便利な機能としてシークレットをenvironmentに紐づけて管理することが可能です。例えば今まではdev環境とprod環境のそれぞれのサーバーにデプロイするための認証情報をそれぞれ DEV_TOKEN, PROD_TOKEN のような別名で登録しておき、条件分岐で使い分けるというワークフローを作っていたかと思います。

environment機能を使うと、dev 環境の TOKEN、prod 環境の TOKEN のように同名のシークレットを別々の環境に登録することが可能です。そしてワークフローでenvironment: dev と指定すると${{ secrets.TOKEN }} の中身は dev 環境に登録した TOKEN の中身に自動的に切り替わるといった具合です。

パラメータのenvironmentの利用

話をinputs におけるenvironmentに戻しましょう。

type: environment とした場合、設定済みのenvironmentの名前が自動的に登録されたプルダウンのUIになります。devとprodの2つを作成済みであれば、プルダウンの中身は自動的にその2つになります。

選択したenvironmentは他のパラメータと同様に参照が可能なのでenvironment: ${{ github.event.inputs.environment }}としてやることで、そのジョブの中では指定したenvironmentに紐づくシークレットを参照することが可能です。
今回のサンプルでは事前にdevとprodそれぞれのenvironmentにENV_SERVERという名前で異なるシークレットを登録しており echo "Deploy target server: ${{ secrets.ENV_SERVER }}" は指定したenvironmentによって中身が切り替わることになります。

今回は単にechoするだけですが、実際のデプロイジョブではデプロイ先サーバー名やトークンなどを登録することになるかと思います。

まとめ

この機能が発表されたときに興奮のあまり雑な感想ツイートをしていたのですが、なぜか予想以上に反応してくれる方が多かったので自分自身でも一応動作確認はしておくかと思い筆を取りました。

（半分は冗談のつもりだったのですが、2021年にJenkinsの手動ジョブをなくしたいと考えている同志がこんなにいる・・・のか？）

正直、choiceやdefault、descriptionの機能が追加されただけでもかなり実用的になったと思っているのですが、environmentとの連携も一緒に追加してもらえたのはかなり嬉しいですね。

そろそろ個人orgのプライベートリポジトリでもenvironemt機能を使えるようにしてくれないかなぁ

参考公式ドキュメント

on.workflow_dispatch.inputs について。inputs のパラメータの構造については次のドキュメントを参照ということが書いてある。

もともとはActionsを自作する場合の inputs としての機能のドキュメントですが、今回のworkflow_dispatchの拡張はこれを流用しているっぽい

environment機能について

脚注

特にGithub Pull Request Builderプラグインの設定をちゃんと理解できた上で設定している人はそう多くないと思います。 ↩︎
さらにJenkinsはプラグインで拡張することも可能だったので、例えばビルドマシンにインストールされているツールのバージョンのプルダウンを自動生成するみたいなことすら可能でした。 ↩︎