octocovで複数のマトリクスに対応すると密結合が避けられない

octocov では環境変数などを使えば複数のマトリクスに対応できるが、どうやってもワークフローとリポジトリの密結合になる。

例えば以下の設定において、

diff:
  datastores:
  - artifact://${GITHUB_REPOSITORY}
report:
  datastores:
  - artifact://${GITHUB_REPOSITORY}

これで matrix を使ったテストを実行すると、2つ目以降のランナーがエラーで失敗する。

$ go test -coverprofile=cover.out
$ octocov -r cover.out
Storing report...
Error: already_exists
Error: The process '/usr/local/bin/octocov' failed with exit code 1
    at ExecState._setResult (/home/runner/work/_actions/actions/github-script/v7/dist/index.js:1702:25)
    at ExecState.CheckComplete (/home/runner/work/_actions/actions/github-script/v7/dist/index.js:1685:18)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/actions/github-script/v7/dist/index.js:1579:27)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1105:16)
    at ChildProcess._handle.onexit (node:internal/child_process:305:5)

1つ目のランナーが artifact://${GITHUB_REPOSITORY} に成果物を保存しているのでエラーとする挙動は正しい。しかしこの場合、複数のマトリクスに対応しようとすると artifact://${GITHUB_REPOSITORY}/${MATRIX_KEY} のような、 matrix で指定した条件ごとに一意な名前を指定しなければならない。

このとき、Actions側で matrix のハッシュを計算すればいいのだが、octocov-action を記述する場所がReusable Workflowとして別のリポジトリになっている場合は問題が複雑化する。例えばワークフローリポジトリでハッシュを計算するとして、それを参照するのは別のリポジトリに置かれている octocov.yml ファイルなので、この依存が蜜結合になる。

Coverallsの場合は、この一意なキーは flag-name としてアクション側に渡していたので問題にならなかった。