fix(elixir): auto-merge lock file maintenance, and narrow its window

[toshi0806]

#165 が Elixir 系 8 PR のうち 4 本（elixir dependencies）を止めていた原因を扱うのに対し、こちらは残る 4 本（lock file maintenance）です。原因が別なので分けています。

症状

止まっている 8 本の PR 本文を読み比べると、はっきり分かれます。

#23 (elixir dependencies):    🚦 Automerge: Enabled.
#24 (lock file maintenance):  🚦 Automerge: Disabled by config.

後者は設定どおりの挙動で、branch protection を入れても動きません。

原因

{"matchManagers": ["mix"], "matchDatasources": ["hex"],
 "matchUpdateTypes": ["minor", "patch", "digest", "lockFileMaintenance"], "automerge": true}

lock file refresh は datasource を持たないため、matchDatasources がこの rule から締め出しています。 matchUpdateTypes に lockFileMaintenance と書いてあるのに一度も効いていない、自己矛盾した状態でした。

npm.json の同等ルールには matchDatasources がなく、だから latex 系では同じ週に lockfile PR が自動マージされています。

対応

matchDatasources を外すのではなく、rule を分けました。あの絞り込みは git 依存を自動マージの対象から外す意図があるはずで、それを壊さずに lockFileMaintenance だけを通すためです。

-      "matchUpdateTypes": ["minor", "patch", "digest", "lockFileMaintenance"],
+      "matchUpdateTypes": ["minor", "patch", "digest"],
       "groupName": "elixir dependencies",
       "automerge": true
+    },
+    {
+      "matchManagers": ["mix"],
+      "matchUpdateTypes": ["lockFileMaintenance"],
+      "automerge": true

効かない記述を元の rule に残すと、読んだ人が「lockFileMaintenance も automerge される」と誤解するので削っています。matchManagers は npm.json と揃えました。

窓も同時に狭めます

 "lockFileMaintenance": {
   "enabled": true,
-  "schedule": ["on sunday and monday"]
+  "schedule": ["before 5am on sunday"]
 }

automerge を有効にするだけだと、#157 で観測したループが Elixir 系でも始まります。 lock file maintenance は job が汲み尽くせる「項目」ではなく「コミットされた lockfile と registry の差」なので、マージすると数時間で差が復活し、2 日窓の中の次の job がまた PR を作ります。latex 系では 08-27〜08-29 の窓で 7 本作られ、うち 1 本は前の PR のマージ 36 秒後でした。

Elixir 系で今それが起きていないのは、automerge が動いていないからにすぎません。 この PR で automerge を通す以上、窓の修正とセットにする必要があります。#158 が latex.json に施したのと同じ形（1 日・夜明け前、Renovate デフォルトの形を曜日だけ動かす）です。5 時間は Mend の job 間隔 4 時間より広いので、窓が 2 つの job の間に落ちる失敗には戻りません。

影響範囲

elixir#v1 を extend する 9 リポジトリすべてに届きます。DNS 系 5 リポジトリ（automerge が正常動作中）も対象なので、あちらの lock file maintenance も日曜早朝の 1 窓に変わります。mudan-dns セッションには別途共有します。

順序

#165（branch protection）とは独立ですが、#165 を先にマージするのが自然です。protection が入るまでは elixir dependencies 側が動かないので、この PR だけ入れても lockfile の 4 本しか流れません。

[github-actions]

全体的に、問題の原因分析・修正方針・副作用への対処がすべて整合しており、変更内容は適切です。以下に気になった点を1点挙げます。

[github-actions]

⚠️ [MEDIUM] 新しいルールに matchDatasources が存在しないことは意図的（lockFileMaintenance はデータソースを持たないため）ですが、matchPackagePatterns や matchDepTypes などの追加フィルタも一切ないため、mix マネージャーが管理するすべてのリポジトリの lockFileMaintenance PR が無条件に automerge されます。

PR 本文では「git 依存を自動マージ対象から外す意図」に言及していますが、lockFileMaintenance の場合は git 依存のバージョン固定も lock ファイルに含まれます。git 依存が含まれるリポジトリで lock ファイルが更新された場合、その変更も自動マージされることになります。

意図的にそれを許容するのであれば、description にその旨を明記しておくと、将来の読者が誤解しにくくなります。

[toshi0806]

DNS 系からの実測データ

elixir#v1 を extend する DNS 系 5 リポジトリを担当している側から実測が届いたので、影響範囲の裏付けとして記録します。この変更は DNS 系にとっても改善でした。

1. 窓を狭めても不利益がない

2 日窓の状態で、過去に作られた lockfile PR は 8/16 の 1 回だけです。

tenbin_dns    #135 created=08-16T17:51 merged=08-17T01:53 +1/-1
tdig          #90  created=08-16T16:29 merged=08-17T01:55 +2/-2
tenbin_cache  #132 created=08-16T16:39 merged=08-17T01:53 +1/-1
elixir_dnstap #41  created=08-16T18:08 merged=08-17T01:55 +0/-0

Elixir 側は依存本数が少なく transitive の入れ替わりもほとんどないため、週 1 本で困る事情はないとのことです。npm 系（textlint 9 パッケージ＋その transitive）とは規模が違います。

2. DNS 系でも automerge は効いていませんでした

上の merge 時刻がそれを示しています。4 リポジトリのマージが 01:53:32 / 01:53:37 / 01:55:22 / 01:55:26 と 2 分間に集中している一方、作成からは 8〜9 時間空いています。

Renovate の job による自動マージなら各リポジトリの job タイミングに散るはずで、この集中は人が続けて操作した形です。 Automerge: Disabled by config. が DNS 系でも同じように出ていたことになります。

つまりこの PR は、Elixir 系 4 ツールの停止を解くだけでなく、DNS 系で毎回発生していた手動マージも不要にします。

3. 差分ゼロの PR が実在しました

elixir_dnstap#41 の +0/-0 を確認したところ、API の集計値ではなく実際に変更ファイルが 0 件でした。

$ gh api /repos/smkwlab/elixir_dnstap/pulls/41/files
(空)

lockfile に差がない状態でも lock file maintenance の PR が作られたことになります。#157 に書いた「マージすると差が復活し、窓の中の次の job がまた作る」の裏返しで、差がなくても作るなら窓を狭める理由がもう一つ増えます。

ただし作成の 8 時間後にマージされているので、作成時点では差があり、その間に別経路で同じ状態になった可能性も残ります。断定はできません。 窓を狭める判断はこれに依存しないので、深追いはしていません。