何を見るチェックか
Scorecard は、直近のマージ済み Pull Request（既定で30件程度）を調べ、 それぞれに CI の実行記録が付いていて、成功しているかを確認します。
対象になるのは、
- GitHub Actions のワークフロー実行
- Travis CI / CircleCI / Jenkins / Azure Pipelines などのステータスチェック
CI が成功していた Pull Request の割合が、そのまま点になります。
テストの中身は見ていません。
echo "ok" だけのワークフローでも、実行されて成功していれば数えられます。
点が低いと何を意味するか
点が低いということは、変更がマージされる前に、自動で検査された記録が確認できない、 という意味です。
これが問題になるのは次のような場面です。
- 壊れた変更がそのままリリースに届く
- 依存を更新したときに、互換性が壊れたことに気づけない
- レビューする人が、動作確認をすべて手元でやることになる
Code-Review が人の目、CI-Tests が機械の目にあたります。 どちらも無い場合、変更は何も通らずに main へ入っていることになります。
逆に、レビューが無くても CI が厚ければ、機械が一定の役目を果たします。
誤解しやすい点
「CI が通っている」と「テストが十分にある」は別のことです。
この項目は CI の実行記録しか見ていません。次のどれも 10点になります。
- テストが1件しかない
- 網羅率が 5% しかない
- ワークフローが lint だけを走らせている
- テストが実質的に何も検証していない
逆に、次のような理由で低く出ることもあります。
- 直接コミットで開発している。 Pull Request が無いので検査対象がありません。 1人プロジェクトでは普通のことです
- CI を使っていないが、リリース前に手で入念に検査している
- ステータスチェックの名前や仕組みが Scorecard の想定と違う
さらに注意点として、この項目が高いことが「品質が高い」を意味しません。 それを見たいなら、リポジトリのテストディレクトリを開いて、 実際に何が検証されているかを見るしかありません。 Scorecard に限らず、自動判定でテストの質は測れません。
採用する側が確認すべきこと
-
リポジトリの
Actionsタブを開く。 実行が並んでいるか、失敗が放置されていないかを見ます。 -
ワークフローファイルを開く。
.github/workflows/を見れば、何を走らせているかは数十秒で分かります。 テストなのか lint だけなのか、複数のバージョンで検証しているかが読めます。 -
テストディレクトリを見る。
tests/やspec/の中身の量が、実質的な判断材料になります。 -
Code-Review と合わせて読む。 人の目と機械の目のどちらか一方があれば、まず極端な事故は起きにくくなります。 両方が 0 のプロジェクトを重要な用途に使う場合は、 あなたの側でバージョンを固定し、更新時に自分で検証する前提を置いてください。
メンテナーなら何を改善できるか
GitHub Actions のワークフローを1つ置き、Pull Request で走るようにします。
name: CI
on:
push:
branches: [main]
pull_request:
permissions:
contents: read # → Token-Permissions
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
version: ['8.3', '8.4', '8.5'] # サポートする範囲で回す
steps:
- uses: actions/checkout@v4
- run: composer install --no-interaction
- run: vendor/bin/phpunit
あわせてやると効果が大きいこと。
- Branch-Protection で CI の成功を必須にする。 走っているだけで、落ちてもマージできる状態だと意味が半減します。
- 失敗を放置しない。 赤いまま何週間も置かれた CI は、誰も見なくなります。
- 1人プロジェクトでも Pull Request を通す。 レビューにはなりませんが、CI が必ず走る経路になります。