Skip to content

fix(protection): declare the four Elixir tools - #165

Merged
toshi0806 merged 1 commit into
mainfrom
protect-the-four-elixir-tools
Sep 2, 2026
Merged

fix(protection): declare the four Elixir tools#165
toshi0806 merged 1 commit into
mainfrom
protect-the-four-elixir-tools

Conversation

@toshi0806

Copy link
Copy Markdown
Member

#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 がこう答えます。

$ gh api /repos/smkwlab/ecosystem-manager/commits/<sha>/status
state: pending   total_count: 0

何も走っていないから pending なのではなく、一度も報告されていないから pending です。 platformAutomerge: false によりマージするのは Renovate 自身で、Renovate はこの status が green になるのを待つので、待ち続けることになります。

切り分け

同じ elixir#v1 preset を extend する DNS 系 5 リポジトリでは automerge が動いています。

tenbin_dns   #137 created=2026-08-30T02:37  merged=2026-08-30T04:38
tenbin_cache #134 created=2026-08-30T01:37  merged=2026-08-30T06:27

同じ日・同じ preset で、片方だけ止まっています。 差分は本宣言に載っているかどうかだけです。

protection automerge
止まっている 4 ツール Branch not protected 止まる
DNS 系 4 リポ ci / Code Quality, ci / All checks / strict=true 動く

Dialyzer のジョブ名未展開(#150)は DNS 系でも同じ表示のまま automerge が成立しているので、原因ではありません。

設定値の根拠

strict: true — 本ファイルの invariant がすでにこう定めています。

latex 系は false。… elixir 系は true のまま置いている。マージが月 0〜4 件で再ビルドの費用が出ておらず、個別には緑でも組み合わせると壊れる PR の検出を優先している

4 ツールはこの条件に当てはまり、DNS 系の実設定とも揃います。

contexts の 2 つ — 4 リポジトリすべてで実際に check run が生成されることを確認しました。invariant の「その PR で必ず check run が生成されるジョブだけを列挙する」に従い、次の 2 つは除外しています。

マージ後にやること

./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 で扱います。

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

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

全体的に変更の意図が明確で、PR 本文の説明も詳細です。1 点だけ指摘します。

},
{
"name": "ecosystem-manager",
"allow_auto_merge": false,

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ [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 する」という前提に反して設定が異なることになり、将来の混乱を招く可能性があります。

@toshi0806
toshi0806 merged commit 2d4438f into main Sep 2, 2026
2 checks passed
@toshi0806

Copy link
Copy Markdown
Member Author

適用完了、ただしメカニズムの説明は訂正します

apply-repo-protection.sh --apply を実行し、audit が drift: 0 件 / missing: 0 件 / errors: 0 件 になりました。既存 11 リポジトリは適用前も ok だったので、実際に変わったのは 4 ツールだけです。

$ gh api /repos/smkwlab/ecosystem-manager/branches/main/protection
checks=ci / Code Quality, ci / All checks  strict=true

しかし combined status は保護適用後も変わりませんでした。

$ gh api /repos/smkwlab/ecosystem-manager/commits/<sha>/status
state: pending   total: 0        ← 適用前と同じ

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 が ignoreTests: false(既定)のもとで「このリポジトリにはテストが設定されている」と判断する材料に branch protection の required checks を使っており、それが無いと automerge の判定に入らない、という筋です。ただし Renovate の実装を読んで確認したわけではないので、これも仮説にとどめます。

私が観測した state: pending, total: 0 は事実ですが、それを原因と断定したのは早すぎました。保護を入れても消えない以上、原因ではありえません。

検証

対処の方向は相関から支持されるので、この 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 の配信(v1 の移動)が要るので、そちらとは切り分けて観察できます。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant