fix(protection): declare the four Elixir tools - #165
Conversation
Without protection a repository has no required status checks, and GitHub's combined status API then answers `state: pending, total: 0` -- pending because nothing was ever reported, not because something is running. Renovate merges on its own here (platformAutomerge is false), and it waits for that status to turn green, so it waits forever. ecosystem-manager #23, registry-manager #91, thesis-monitor #71 and elixir-tool-kit #19 have sat open since 2026-08-30 with every check run green and `Automerge: Enabled` in their bodies. The five DNS repositories extend the same elixir preset, carry this protection, and merged their 2026-08-30 updates within hours. strict is true, matching the invariant above and the DNS repositories: these tools merge zero to four times a month, so the rebuild cost of an up-to-date requirement does not arise. The contexts name only the two jobs that always produce a check run. The matrix Test jobs carry the OTP and Elixir versions in their names, and the Dialyzer job's name is still an unexpanded expression (#150), so neither can be depended on. Refs #152
| }, | ||
| { | ||
| "name": "ecosystem-manager", | ||
| "allow_auto_merge": false, |
There was a problem hiding this comment.
ℹ️ [LOW] 4 リポジトリすべてで "allow_auto_merge": false が設定されています。PR 本文では「Renovate 自身がマージする(platformAutomerge: false)」と説明されており、GitHub の auto-merge 機能は使わないという理解は正しいです。
ただし、将来的に platformAutomerge: true へ切り替えた場合、この設定が障害になります。また、既存の DNS 系リポジトリ(tenbin_dns など)の設定と比較して allow_auto_merge の値が一致しているか確認することを推奨します。もし DNS 系が true であれば、「同じ preset を extend する」という前提に反して設定が異なることになり、将来の混乱を招く可能性があります。
適用完了、ただしメカニズムの説明は訂正します
しかし combined status は保護適用後も変わりませんでした。 PR 本文とコミットメッセージで「required status checks が無いから combined status が pending になり、Renovate がそれを待ち続ける」と書きましたが、この説明は成り立ちません。combined status API が見るのは commit status であって、branch protection の required checks でも check runs でもありません。保護を入れても 0 件のままです。 確実なこと・不確実なこと確実なのは相関です。 保護のある DNS 系 5 リポジトリでは automerge が動き、保護のない 4 ツールでは 4 日間止まった。同じ preset・同じ日・同じ Dialyzer 未展開表示(#150)で、差分は保護の有無だけでした。この観察は変わりません。 不確実なのは因果の経路です。 より確からしいのは、Renovate が 私が観測した 検証対処の方向は相関から支持されるので、この PR を取り消す必要はないと考えています。実証は次の Renovate jobです。ecosystem-manager #23 / registry-manager #91 / thesis-monitor #71 / elixir-tool-kit #19 が自動マージされれば、保護の追加で解決したことになります。されなければ別の原因を探す必要があり、その場合は Mend portal の job log が次の手がかりです。 なお lock file maintenance 側の 4 本(#24 / #92 / #72 / #20)は #166 の配信( |
#152 の対応。Renovate PR が 4 日間止まっている原因がこれでした。
症状
ecosystem-manager #23 / registry-manager #91 / thesis-monitor #71 / elixir-tool-kit #19 が 2026-08-30 の作成以来 OPEN のままです。いずれも全 check run が green、
MERGEABLE/CLEAN、PR 本文にも🚦 Automerge: Enabled.と書かれています。原因
保護がないリポジトリは required status checks を持たないため、combined status API がこう答えます。
何も走っていないから pending なのではなく、一度も報告されていないから pending です。
platformAutomerge: falseによりマージするのは Renovate 自身で、Renovate はこの status が green になるのを待つので、待ち続けることになります。切り分け
同じ
elixir#v1preset を extend する DNS 系 5 リポジトリでは automerge が動いています。同じ日・同じ preset で、片方だけ止まっています。 差分は本宣言に載っているかどうかだけです。
ci / Code Quality,ci / All checks/strict=trueDialyzer のジョブ名未展開(#150)は DNS 系でも同じ表示のまま automerge が成立しているので、原因ではありません。
設定値の根拠
strict: true— 本ファイルの invariant がすでにこう定めています。4 ツールはこの条件に当てはまり、DNS 系の実設定とも揃います。
contexts の 2 つ — 4 リポジトリすべてで実際に check run が生成されることを確認しました。invariant の「その PR で必ず check run が生成されるジョブだけを列挙する」に従い、次の 2 つは除外しています。
ci / Test on OTP 27.3.4.16 / Elixir 1.17.3— マトリクスの版がジョブ名に入るため、版が変わると context 名も変わるci / Dialyzer Analysis on OTP ${{ inputs.otp-version-latest }} / ...— 名前が未展開の式のまま(elixir-ci: PR のチェック一覧で Dialyzer ジョブ名が未展開の式のまま表示される #150)マージ後にやること
./scripts/apply-repo-protection.sh --applyの手動実行が必要です。 スクリプトの注記どおり App token ではなく管理者の個人トークンで実行します。適用後、止まっている 4 本が Renovate の次の job でマージされるかどうかが、この診断の検証になります。なお lock file maintenance 側の 4 本(#24 / #92 / #72 / #20)は
🚦 Automerge: Disabled by config.で、これは別の原因です。elixir.jsonの rule がmatchDatasources: ["hex"]で絞っており、datasource を持たない lockFileMaintenance にマッチしていません。そちらは別 PR で扱います。