GitHub Actionsを手動実行するworkflow

GitHub Actionsのトリガーの1つで手動でトリガーをかけるworkflow_dispatch について。

workflow_dispatch
inputs
設定例
実行例

workflow_dispatch

GitHub Actionsのトリガーとして、workflow_dispatchというものがあります。

Events that trigger workflows - GitHub Docs

これをworflowファイル内のonの部分に加えると workflowのページにRun workflowのボタンが出来て手動でも実行できるようにもなります。

手動実行の際にinputsで指定した変数を入力することが出来ます。

inputs

inputsにはtypeとしてstring、choice、boolean(true or false)、environmentが使えます。

GitHub Actions: Input types for manual workflows GitHub Changelog

workflow_dispatchのところからContexts - GitHub Docsへのリンクがありますが、こちらのinputsのところをみると string、number、booleanとあって、choiceとかの説明がちょっと見当たりませんでした。ドキュメントがまだアップデートされてない？(結構時間経ってますが。)

それぞれ

string: 文字列。Run workflowでは自由に書ける入力欄になる。
choice: optionsという値にリストを与え、その中から選ぶようなプルダウンを生成する。defaultが指定されてなければ(もしくはリストに無いものが指定されてたら)一番上のものがdefaultとして出る。
boolean: true or false
enviroment: レポジトリのSettings Environmentsで作った環境の名前のリストから選ぶプルダウンを生成する。defaultがなければ一番上の環境の名前がdefualtとして出る。

その他numberなど本来ないtypeを指定すると、エラーにはなりませんが単にstringと同様に扱われるようになっているみたいでした。 (数字だけ選べる、とかにはならない。またtest_typeみたいな意味のないのを入れても普通にstring typeと同じように使える。)

設定例

test.yml

---
name: test

on:
  push:
    branches-ignore:
      - "coverage"
  pull_request:
  workflow_dispatch:
    inputs:
      string_var:
        type: string
        description: 'string variable'
        required: false
        default: 'default string'
      choice_var:
        type: choice
        description: 'choice variable'
        required: false
        default: 'b'
        options:
          - 'a'
          - 'b'
          - 'c'
      boolean_var:
        type: boolean
        description: 'boolean variable'
        required: false
        default: false
      environment_var:
        type: environment
        description: 'enviroment variable'
        required: false
        default: prod
      number_var:
        type: number
        description: 'number variable'
        required: false
        default: 1
      test_type_var:
        type: test_type
        description: 'test_type variable'
        required: false
        default: abc

jobs:
  test:
    runs-on: ubuntu-latest
    environment: ${{ inputs.environment_var }}
    steps:
      - name: inputs check
        run: echo "string_var=${{ inputs.string_var }}, choice_var=${{ inputs.choice_var }}, boolean_var=${{ inputs.boolean_var }}, environment_var=${{ inputs.environment_var }}, number_var=${{ inputs.number_var }}, test_type_var=${{ inputs.test_type_var }}"
      - name: boolean test
        if: ${{ inputs.boolean_var }}
        run: echo "boolean_var is true"
      - name: string test
        if: ${{ inputs.string_var }}
        run: echo "string_var is true"
      - name: environment test
        run: echo "TEST_VAR=${{ vars.TEST_VAR }}"

pushやpull_requestと同じようにworkflow_dispatchを設定します。

inputsにtypeとしてstring、choice、boolean、environment以外にもnumber、test_typeのものも入れています。

また、このレポジトリではEnvironmentsでdev、prodという環境を作って、それぞれ TEST_VARという変数をEnvironment variablesの中で

dev: This is a development environment.
prod: This is a production environment.

という感じに設定してあります。

このworkflowを作ると、Run workflowの中はこんな感じになります。

choice、environmentのところがプルダウンになっていてbooleanの所がチェックボックスになっているのがわかります。

他のところはstringを含めすべて自由入力欄です。

実行例

push時

pushのときにはworkflow_dispatchのinputsの値はすべて空になります。

従ってboolean test、string testのif文は通りません(定義なしはfalse判定)。

また、environmentの設定もからなのでvars.TEST_VARも設定されないまま空です。

手動実行時

Run workflowボタンから実行すると、実行リストではManual runと表示されます。

上のworkflowで設定を変えないまま走らせてみるとこんな感じの結果になります。

今度はstring testは実行されています。値はdefault stringという文字列ですが、${{ ... }}で単に値を指定した時、文字列であれば空でなければ通るようです。

enviroment testでTEST_VARの値がprodのものになっていることが分かります。

また、number_varやtest_type_varはtypeの値がおかしくてもstringのように扱われています。

手動実行時、値変更

値を変更して実行してみます。

string_var: default_string -> false
choice_var: a -> b
boolean_var: false -> true
environment_var: prod -> dev
number_var: 1 -> xyz

結果はこんな感じ。

string_varをfalseという文字列にしてもやはり文字列なので空で無い限り成功になります。数字の0とかを入れても文字列とみなされてtrueになります。

ちなみに入力欄を空のまま実行するとdefaultの値になるので上のworkflowでは手動実行の場合には必ずstring testが実行されることになります。

boolean testは今回は実行されています。このような感じで値だけで評価する際にはboolean typeのみが使えるようです。

文字列の場合には

if: ${{ inputs.string_var == 'ok value' }}

の様な感じで比較でチェックを行えば必要な文字列の時だけ通す事ができます。

environment_varも変更によって正しくdevelopmentな環境の変数が取れています。

また、number_varに関しては文字列を入れましたがそのまま受け入れられてやはり単に stringと同じ扱いになっています。