GitHub Actionsのワークフロー再利用を試してみる

これ

GitHub Actions: DRY your GitHub Actions configuration by reusing workflows | GitHub Changelog

Now available in public beta, you can reuse entire workflows as if they were an action. Instead of copying and pasting workflow definitions across repositories, you can now reference an existing workflow with a single line of configuration.

Reusing workflows are great for reducing configuration. Here’s a few examples:

Create a workflow for building your homegrown framework so your users can quickly setup CI

Create a workflow to deploy to production, and reference it from each repository of your microservice application

Create a workflow to roll up end-of-sprint metrics, and encourage every team to add it to their repository

翻訳

パブリックベータ版では、あたかもアクションのようにワークフロー全体を再利用できるようになりました。リポジトリ間でワークフローの定義をコピー＆ペーストするのではなく、1行の設定で既存のワークフローを参照できるようになりました。

ワークフローの再利用は、設定を減らすのに最適です。いくつか例を挙げてみましょう。

自作のフレームワークを構築するためのワークフローを作成し、ユーザーが素早くCIを設定できるようにする。
本番環境にデプロイするためのワークフローを作成し、マイクロサービス・アプリケーションの各リポジトリから参照する。
エンドオブスプリントのメトリクスをロールアップするワークフローを作成し、各チームにリポジトリへの追加を促す

Futa Hirakoba

ドキュメントを読みつつ考える

Reusing workflows - GitHub Docs

Futa Hirakoba

Access to reusable workflows

再利用可能なワークフローは以下のいずれかに該当する場合、他のワークフローから利用できる。

どちらのワークフローも同じリポジトリにある。
呼び出されるワークフローは、publicリポジトリに保存されている。
呼び出されるワークフローは、internalリポジトリに保存されており、そのリポジトリの設定によってアクセスできるようになっている（詳細）

Futa Hirakoba

Limitations

制限事項

再利用可能なワークフローは、他の再利用可能なワークフローを呼び出すことができない
privateリポジトリ内に保存された再利用可能なワークフローは、同じリポジトリ内のワークフローでのみ使用できる
呼び出し元のワークフローでワークフローレベルで定義されたenvコンテキストで設定された環境変数は、呼び出されたワークフローには伝わらない

今後外される制限事項

再利用可能なワークフローは、自前のランナーを参照できない
呼び出されたワークフローのconcurrencyを、呼び出し元のワークフローから設定することはできない
呼び出されたワークフローで生成されたoutputは、呼び出し元のワークフローからアクセスできない

Futa Hirakoba

Creating a reusable workflow

再利用可能なワークフローは、リポジトリの.github/workflowsディレクトリに配置する。
workflowsディレクトリのサブディレクトリはサポートされていない。

呼び出されるワークフローはon.workflow_callを設定する。

on:
  workflow_call:

inputsとsecretsを定義することで呼び出し側のワークフローから呼び出されたワークフローに情報を渡すことができる。

on:
  workflow_call:
    inputs:
      ring:
        description: 'Identifier for the target deployment ring'
        default: 'ring-0'
        required: false
        type: string
      environment:
        required: false
        type: string
    secrets:
      token:
        required: false

Futa Hirakoba

Calling a reusable workflow

usesで呼び出す。アクションを使う場合と異なり、step内では使用せずにjobs.<job_id>.usesで指定する。

書式はこんな感じ。{owner}/{repo}/{path}/{filename}@{ref}
同じリポジトリでもこういうふうに指定しないといけないのはちょいめんどい。

jobs:
  call-workflow-1:
    uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89
  call-workflow-2:
    uses: octo-org/another-repo/.github/workflows/workflow-2.yml@v1

Futa Hirakoba

Invalid workflow file : .github/workflows/reusable-workflow-b.yaml#L1

handling usage of workflow "korosuke613/playground/.github/workflows/reusable-workflow-a.yaml@HEAD": can't obtain workflow file: reference to workflow should be either a valid branch, tag, or commit
https://github.com/korosuke613/playground/actions/runs/1314931307

おっと。HEADの指定はダメ？そうなると開発中はブランチを指定した方がいいか

Futa Hirakoba

The workflow is not valid. .github/workflows/reusable-workflow-b.yaml (Line: 8, Col: 11): Input username is required, but not provided while calling. .github/workflows/reusable-workflow-b.yaml (Line: 8, Col: 11): Secret token is required, but not provided while calling.
https://github.com/korosuke613/playground/actions/runs/1314949648

お、inputsとsecretsを無視したら怒られた。

Futa Hirakoba

動いた動いた。もちろんsecretsはマスクされた https://github.com/korosuke613/playground/actions/runs/1314956401

Futa Hirakoba

Supported keywords for jobs that call a reusable workflow

再利用可能なワークフローを呼び出す際には、呼び出しを含むジョブ内で以下のキーワードのみを使用できる。

jobs.<job_id>.name
jobs.<job_id>.uses
jobs.<job_id>.with
jobs.<job_id>.with.<input_id>
jobs.<job_id>.secrets
jobs.<job_id>.secrets.<secret_id>
jobs.<job_id>.needs
jobs.<job_id>.if
jobs.<job_id>.permissions
- ダウングレードのみ可能。

ifとpermissionsが使える。

Futa Hirakoba

ジョブが失敗したときにSlackに通知したり、ワークフローからワークフローを呼び出す^[1]のが楽になる。

自前Actionは再利用できるjobという感じだった（設定もちょっとめんどかった）。
再利用ワークフローは複数jobをまとめて再利用できるのが嬉しいのかも。デプロイするなどは確かにアクションより優れるか？

脚注

今まではrepository_dispatchかなんかして別ワークフローとしないといけなかったし ↩︎

Futa Hirakoba

しかし、、mainに無いワークフローを指定するにはトピックブランチ名かコミットハッシュが必要だから受け入れテストする時がむずくない？
mainで指定したいけどそれやるとテスト通らなくなる。となるとコミットを分けてコミットハッシュ指定するしかないのか？

もしくはワークフローに対してタグをつけるか。タグなら変更できるのでワークフローの変更に追従できる（セキュリティ的にはもちろんコミットハッシュ指定がいい）。そうしてみるか

Futa Hirakoba

You can now reference local reusable workflows more easily. With this release, reusable workflows that are in the same repository as the calling repository can be referenced with just the path and filename: {path}/{filename}.
https://github.blog/changelog/2022-01-25-github-actions-reusable-workflows-can-be-referenced-locally/

DeepL: ローカルの再利用可能なワークフローをより簡単に参照できるようになりました。今回のリリースでは、呼び出し元のリポジトリと同じリポジトリにある再利用可能なワークフローを、パスとファイル名（{path}/{filename}）だけで参照できるようになりました。

ローカルだと ref の指定が必要なくなったため使いやすくなった

このスクラップは2021/10/07にクローズされました