elixir.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "github>smkwlab/.github#v1",
    "github>smkwlab/.github:github-actions#v1"
  ],
  "enabledManagers": ["mix", "github-actions"],
  "description": [
    "Raise the Erlang/OTP floor used to regenerate mix.lock. Renovate's mix manager treats its two tools asymmetrically: erlang falls back to a hardcoded `^26` (lib/modules/manager/mix/artifacts.ts), while elixir has no default and floats to the newest release satisfying the `elixir:` requirement in mix.exs. Every repository here allows `~> 1.17` or wider, so Renovate picks Elixir 1.20.x -- which requires OTP 27+ and refuses to install against OTP 26. The install step then aborts with `ERROR! Unsupported Erlang/OTP version, expected Erlang/OTP 27+`, Renovate reports `Command failed: install-tool elixir vX.Y.Z`, mix.lock is left untouched, and the resulting empty commit is dropped (`Detected empty commit - aborting git push`). Every mix lock file update has failed this way since Elixir 1.20.0 was released on 2026-06-03.",
    "Constrain erlang rather than elixir. Pinning elixir low would only avoid the mismatch by accident, and would freeze lock file generation on an Elixir line the projects no longer target. This affects only the toolchain Renovate installs to regenerate lock files; the OTP/Elixir matrix in each repository's CI is configured separately and is unchanged.",
    "Do not narrow this to an exact version. Renovate resolves the constraint against containerbase's erlang prebuilds, which are published as four-component versions (27.3.4.15, not 27.3.4); a range keeps picking up their patch releases.",
    "Open the window across Sunday and Monday. The six-hour Monday window this replaces did clear Mend's four-hour job interval, but only by two hours, and nothing here controls that interval -- it is a property of the Mend plan, and the organisation's queue runs one or two jobs at a time. A schedule never starts a run; it only tells a run already under way whether it may act, so a window narrower than the interval between runs can fall entirely between two of them. That is how the latex preset's three-hour window left half of its repositories without a single pull request for three weeks. Two days removes the dependency on a two-hour margin, and placing them opposite that preset's Friday and Saturday keeps the two families' bursts apart.",
    "Give lock file maintenance a narrower window than the two days above. It carries its own schedule that the top-level one does not override, so a window has to be named here whatever the choice, and the reasoning for widening does not carry: a lock file refresh is not an item a job can exhaust but the difference between the committed lock file and the registry. Merging it restores that difference within hours, so the next job inside a two-day window has something to create again. The latex preset's window of 2026-08-27 produced seven pull requests across the two repositories that carry lock files, one opened thirty-six seconds after its predecessor merged.",
    "Place that window in daylight. Mend's jobs run three to four hours apart through the day but stretch overnight, so a narrow window is reachable or not depending on where it sits rather than how wide it is. A five-hour window from midnight caught no job at all on 2026-09-04 and the update sat under Awaiting Schedule for the whole of that day. Six hours from 6am takes in the two jobs one refresh needs -- the first creates the pull request, the second merges it once the checks are green -- and leaves out the third, which is the one that would start the cycle over."
  ],
  "constraints": {
    "erlang": "^27"
  },
  "schedule": ["on sunday and monday"],
  "lockFileMaintenance": {
    "enabled": true,
    "schedule": ["after 6am and before 12pm on sunday"]
  },
  "packageRules": [
    {
      "description": "Intentional exception to the org-wide patch/digest-only auto-merge policy: Elixir (hex) packages are reliably semver-compliant, so minor and lockFileMaintenance updates are grouped and auto-merged as well. Which updates auto-merge is the exception; who merges them is not -- Renovate merges these, like every other auto-merged update, once it has seen all check runs go green. The required status check here is `ci / Code Quality` alone, so GitHub's auto-merge would release the merge while the OTP/Elixir test matrix is still running.",
      "matchManagers": ["mix"],
      "matchDatasources": ["hex"],
      "matchUpdateTypes": ["minor", "patch", "digest"],
      "groupName": "elixir dependencies",
      "automerge": true
    },
    {
      "description": "Auto-merge lock file maintenance too. It cannot ride on the rule above: a lock file refresh carries no datasource, so matchDatasources there -- which is deliberate, keeping git dependencies out of the auto-merged lane -- excludes it. Naming lockFileMaintenance in that rule's matchUpdateTypes therefore did nothing, and the mix lock refreshes sat unmerged from 2026-08-30 while the npm ones, whose rule has no datasource filter, merged the same week.",
      "matchManagers": ["mix"],
      "matchUpdateTypes": ["lockFileMaintenance"],
      "automerge": true
    }
  ]
}