QUO CARD Digital Innovation Lab Tech Blog

クオカード デジタルイノベーションラボの技術ブログです

GitHub Actions の composite run steps action を 試してみた

こんにちは、デジタルイノベーションラボで ビルドおじさんを担当している もちだ です。ここ最近の開発言語は HCL です。

今回はちょっと前(2020 年 8 月 7 日)に公開された GitHub Actions の composite run steps action を 試してみました。これは Dockerfile や node js のコードを書かなくても(書けなくても) 通常の GitHub Actions のワークフロー YAML が書ければ、 action を作成・公開できるという仕組みです。

f:id:quo-digital:20200925182049p:plain


作成方法

詳しい作り方は GitHubドキュメント を参照してください。ここでは簡単に示します。

  1. 新しいパブリックリポジトリーを作成する
  2. action.yml を作成し、 inputs/outputs にそれぞれ入力/出力の仕様を記述し、 runs.steps 以下にこれまでと同様な step を記述する
  3. ユーザーが呼び出しやすいようにタグを作成する

これで、ユーザーが作成した action を自分のビルドに取り込めるようになりました。 取り込む方法はこれまでの action と同じく、 <username>/<repository-name>@<tag-name> です。


制限事項

制限事項というほどではないですが、 composite run steps action 検討している方が 考慮しておいたほうが良い通常の GitHub Actions ワークフロー YAML とは異なることを まとめておきます。

他のアクションを uses で参照できない

デジタルイノベーションラボでは Kotlin をサーバーサイドのメイン開発言語に 使っており、よく次の組み合わせの action が典型的なボイラープレートコードに なっています。

- name: setup java
  uses: actions/setup-java@v1
  with:
    java-version: 11
- name: cache gradle files
  uses: actions/cache@v2
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: gradle-${{ hashFiles('gradle/wrapper/*.properties') }}-${{ hashFiles('build.gradle') }}
    restore-keys: |
      gradle-${{ hashFiles('gradle/wrapper/*.properties') }}-
      gradle-

しかし、 action.ymlドキュメント を参照すると明らかである通り、 action.ymlスキーマには runs.steps.uses は存在しません。 そのため、このような action.yml を作ると実行時にエラーが発生します。 ワークフロー YAMLリファクタリングを検討している場合は気をつけてください。

各ステップには必ず shell の指定が必要

各ステップには shell の指定が必要になります。

runs:
  steps:
    - name: show hello
      run: echo "Hello World"
      shell: bash #必須

単純なコピペだけでの移行はできないのでご注意ください。 なお、 shell に指定できるのは bashpwsh(パワーシェル) 、 pythonsh(Linux/macOS) 、 cmd(Windows) 、 powershell(Windows) です

ユーザーのステップからは composite run steps action の各ステップの名前は参照できない

次のような composite run steps action を作ったとします。

runs:
  steps:
    - name: show input
      run: echo "input = ${{ inputs.input }}, ref = ${{ github.ref }}"
      shell: bash
    - name: create hash
      id: hash
      run: echo "::set-output name=value::$( echo "${{ inputs.input }}" | openssl sha1)"
      shell: bash

この action をユーザーのワークフローが呼び出したときのログは次のようになります。

Run user/repo@v1
  Run user/repo@v1
  with:
    input: test
  input = test, ref = refs/heads/master

事前にテストを十分に行う、ドキュメントに事前条件などを丁寧に書くなどして、 ユーザーとの間に誤解が発生する可能性を低減してみてください。

レポジトリーにあるファイルは一切読み込めない

よくファイルなどに設定値を記述しておいて、パラメーターなどによってアウトプットを変更したり、 処理内容を調整するなどはよくやる手段です。 しかし action のレポジトリーのルートディレクトリーにあるファイルは読み取れません。 そのような設定ファイルの読み込み等が必要になるケースの場合は、 composite run steps action ではなく、 Dockerfile action や node js による action を使うことをおすすめします。 (GitHub Actions でのユーザーの処理を考えれば、レポジトリーのファイルが読み取れないのは妥当であるように思います)


制限事項をまとめてみましたが、その他できることとしては次のようなものがあります

できること

  • ユーザーが実行している github オブジェクトの値を読み取る
    • なお secrets は読み取れません
  • ユーザーのワークスペースのファイルを読み取る

テスト方法

テスト方法は簡単です。自分のレポジトリーの master ブランチを uses で指定したワークフロー YAML を用意すれば、テストできます

.github/workflows/test.yml

name: Test
on: [push]

jobs:
  test:
    name: Test
    runs-on: ubuntu-20.04
    steps:
      - name: Call self
        uses: user/repository@master
        id: composite
        with:
          message: "This is test"

      - name: show result
        run: |
          echo "= output ==="
          echo "${{ steps.composite.outputs.hash }}"
          echo "= hash ==="
          echo "This is test" | openssl sha1

以上、 今回はビルドおじさん的な視点から、 GitHub Actions で遊んでみました。 これで読みづらかったワークフロー YAMLリファクタリングが捗りそうな予感間違いなしですね!

ここより下は宣伝です! デジタルイノベーションラボでは新しいものやわからないものでも 積極的に実験して自分のものにしてしまう、 そんな若気の至りに毛が生えたようなクロスファンクショナルなエンジニアを募集しています。 われこそはという方は こちら まで 是非是非ご応募してください!!!!