社内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実行後の結果が正しいかの検証を行う
















