Skip to content

set-codeql-language-matrixへの不満

CodeQLワークフローを作るとき、languages パラメータを何度も書く必要があって面倒だったので便利なものを探していたらadvanced-security/set-codeql-language-matrixというアクションが見つかった。このアクションは開発している人もGitHubのスタッフらしいので使ってみたが、少なくとも2026年3月時点ではイマイチだった。

ジョブがマトリクスを作る部分と他の部分で分かれる

Section titled “ジョブがマトリクスを作る部分と他の部分で分かれる”

Swiftサポートのためだと思うが、ワークフローで以下のように書く必要がある。

jobs:
create-matrix:
runs-on: ubuntu-latest
outputs:
matrix: ${{ steps.set-matrix.outputs.matrix }}
steps:
- id: set-matrix
uses: advanced-security/set-codeql-language-matrix@v1.3.0
with:
access-token: ${{ secrets.GITHUB_TOKEN }}
endpoint: ${{ github.event.repository.languages_url }}
analyze:
needs: create-matrix
strategy:
fail-fast: false
matrix: ${{ fromJSON(needs.create-matrix.outputs.matrix) }}
runs-on: ${{ (matrix.language == 'swift' && 'macos-latest') || 'ubuntu-latest' }}

ここで runs-on を動的に切り替えさせるため、どうしてもマトリクスを作る部分だけで分けなければならない。微々たる違いではあるが、分けてしまうとCIの実行も分かれて見えてしまう。

ワークフローだけを置いたリポジトリの自動検出ができない

Section titled “ワークフローだけを置いたリポジトリの自動検出ができない”

set-codeql-language-matrix は内部でLanguages API(どの言語がどれだけ使われているかを返すAPI)を使っているのだが、共有ワークフローだけ置いているリポジトリではうまく検出してくれない。APIの仕様として .github/ 以下を含まないのかもしれないが、少なくとも自動検出した言語リストが空になってしまって困るので以下のようなグルーコードを追加する必要があった。

- name: Include actions always
id: arrange-matrix
uses: actions/github-script@v8.0.0
env:
MATRIX: ${{ steps.set-matrix.outputs.matrix }}
with:
script: |
const matrix = JSON.parse(process.env.MATRIX)
const defaults = matrix.include.map(v => v.language).includes('actions') ? [] : [
{ language: 'actions', 'build-mode': 'none' }
]
const json = {
...matrix,
include: [ ...defaults, ...matrix.include ]
}
return JSON.stringify(json)
result-encoding: string

困っているのでイシューを作ろうとも思ったけれど、以下2つの問題が致命的だった。

コードは変更されているけどリリースされていない

Section titled “コードは変更されているけどリリースされていない”

2026年3月時点で、リリースは2025年6月の v1.3.0 が最新だった。しかし main ブランチのコードは2025年12月頃まで変更されていて、しかも最終リリースと main ブランチのコードで挙動が異なっている(outputsmatrix を含むようになった)ので、挙動を調べたければ特定タグのソースコードを注意して見なければならない。

余談だけど README に書かれている通りに書いてもうまく動かなくて3時間くらい悩んだ。

EOLのイシューが半年放置されている

Section titled “EOLのイシューが半年放置されている”

上記までなら、まだイシュー書いて対応してもらえばいい、もしくは諦めて違う方法を考えればいいが、Using outdated insecure docker imageが半年放置されているのをみて、このアクションには将来性が無いと判断した。セキュリティ強化のためにあるアクションで脆弱になるとか本末転倒だろう。

上記の他にも、build-modemanual の場合は結局いっぱい書くことがあるなどイマイチだった。