社内github actions現状確認
いろいろ動くようになってきていたのでまとめた。
初期設定
社内action側の https://github.com/${org}/${repo}/settings/actions にある、 Access を Not accessible 以外にする。
できること
過去、 using: "composite" 内から uses: を使うことができなかったが、使えるようになっていた。
呼び出された側のactionでローカルファイルを参照した場合、呼び出し側のローカルファイルが参照される。
参照側
- uses: ${org}/${repo}@${tag or branch}
or
- uses: ${org}/${repo}/${dir_name}@${tag or branch}
${dir_name} が指定された場合、参照先 ${repo} 内の /${dir_name}/action.yml が呼び出される。
ただし、 ${dir_name} が /.github/workflows/${workflow} を参照している場合、workflowの参照とみなされる。 （もしかしたらファイルを参照しているとworkflow、ディレクトリを参照しているとactionとみなしてるかも？）
複数actionsの運用
action毎にrepositoryを作成する
Pros
一般的なgithub actionのプラクティスを適応できる
Cons
管理するrepositoryが増える
一つのrepository内でbranch毎に別のactionを作成し、参照側はbranch指定で呼び出す
Pros
（3と比較して）一般的なgithub actionのプラクティスを適応できる
リポジトリが増えない
Cons
参照側でtagを指定できないため、バージョン管理が煩雑 （ただし、そもそもgithub actionsは @v1 のような指定をしても v1 というタグの指定にしかならないため、 branch_v1 のようなbranch名での運用でも大差ないかもしれない）
開発時に「どのブランチが外部から参照されているか？」が不明なため、間違って参照されているブランチが削除される懸念がある （main branchに外部提供しているactionを列挙し、各branchのCIからmain branchのactionを呼び出して、検証することはできそう）
一つのrepository内でディレクトリを分けてactionを作成し作成し、参照側はディレクトリ指定で呼び出す
Pros
リポジトリが増えない
ディレクトリ毎にactionを管理できるので一覧性が高い
Cons
tag, branchを指定したバージョン管理は困難 （/action_v1 、/action_v2 のようなディレクトリ名を使ったバージョン管理になりそう）
一般的なgithub actionsのプラクティスの適応は困難（monorepoと思えばいけるかも？）
テスト
.github/workflows/on_push.yml に以下のような内容を書く
name: test on: push jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: ./ with: example: aaa # 必要に応じてaction実行後の結果が正しいかの検証を行う
