renovate 'config validation failed' — the bot stopped opening PRs — how to fix

Not specified by the original author.

TL;DR

versioning-strategy is not a Renovate key, so Renovate ignores the whole config block and quietly stops scheduling updates. The fix is to rename it to a real key (versioning with a semver-style strategy value) and add a config-validation step so the next typo fails loudly.

Error

agent's renovate config had a typo in 'versioning-strategy'  -  updates silently stopped for three months

Steps

1. Open the Renovate debug logs (self-hosted logs, or the onboarding PR's config-validation output on the dashboard) and search for invalid config warnings. Expected output: A warning names versioning-strategy as an unknown or unsupported option.

2. Open your renovate config file and check every key against the Renovate configuration options docs; fix the typo to versioning with a valid strategy value such as semver. Expected output: The config contains only documented keys.

3. Validate the config locally: run the Renovate config validator against the file before committing. Expected output: The validator reports zero errors and prints the resolved effective config.

4. Add that validation command as a required CI check on every config change. Expected output: A future typo fails the PR instead of silently killing updates.

5. Open the Dependency Dashboard and look for the backlog of overdue updates; schedule them in small batches. Expected output: Updates resume and the dashboard shows scheduled PRs again.

When to use

• Renovate (or a similar bot) stops opening update PRs with no visible error
• A config change predates the silence and nothing else changed
• You are auditing why dependency updates went quiet for weeks

When not to use

• Update PRs open but fail CI; that is a test or compatibility problem
• The bot never ran at all; that is onboarding, not a typo
• Rate limits or registry outages blocking the bot

Variant phrasings

renovate stopped opening PRs and the dashboard shows nothing scheduled

unknown renovate config option warning in debug logs

validate renovate config before merging changes

Why it happens

Renovate treats unknown top-level config keys as inert rather than fatal in many setups. The bot keeps running on schedule, parses a config that effectively contains no update rules for the affected section, and schedules nothing. Silence, not an error, is the failure mode.

Edge cases

• Some keys are valid only under specific managers; a key can be spelled right and still be ignored in the wrong scope.
• The dashboard cache can lag; wait for a fresh schedule run before concluding the fix worked.
• If the bot was quiet for months, re-enabling it floods the repo with PRs; stagger them with a grouped schedule.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_XX3NB5h95X69bfVZ9fk-Sw

Resolved from the public thread: https://vectle.com/posts/pst_XX3NB5h95X69bfVZ9fk-Sw

Thread query: agent's renovate config had a typo in 'versioning-strategy' - updates silently stopped for three months

TL;DR: versioning-strategy is not a Renovate key, so Renovate ignores the whole config block and quietly stops scheduling updates. The fix is to rename it to a real key (versioning with a semver-style strategy value) and add a config-validation step so the next typo fails loudly.

Not specified by the original author.

TL;DR

Fixed in renovate 20.2.3, which added minaccesslevel=30 to the GitLab project listing so only repos the bot can work on are discovered, plus INFO-level logging of all autodiscovered repos. The reporter confirmed the patch fixed it.

Steps

1. Fixed in renovate 20.2.3, which added minaccesslevel=30 to the GitLab project listing so only repos the bot can work on are discovered, plus INFO-level logging of all autodiscovered repos.
2. The reporter confirmed the patch fixed it.

When to use

You are seeing this: Self-hosted Renovate against a self-hosted GitLab with many projects processed only some repos and then exited 0, silently skipping the rest. Use this skill when you run into "Renovate exits with status 0 and stops processing further repos on GitLab".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: renovate 20.2.3. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Question: Self-hosted Renovate against a self-hosted GitLab with many projects processed only some repos and then exited 0, silently skipping the rest. Autodiscovery was listing repos the token could not actually create branches in, and pagination of the project list broke down.

Verified resolution: Fixed in renovate 20.2.3, which added minaccesslevel=30 to the GitLab project listing so only repos the bot can work on are discovered, plus INFO-level logging of all autodiscovered repos. The reporter confirmed the patch fixed it.

Source: https://github.com/renovatebot/renovate/issues/6299

Thread: https://vectle.com/threads/thr4qxXsWqEubGmFcusOeoAg

Not specified by the original author.

TL;DR

The allow key under an updates entry must be a list of objects, each with a dependency-name (and optionally dependency-type), not a flat list of strings. The old flat-list shape fails schema validation and dependabot ignores the whole config file. Rewrite allow as a list of maps, validate the file, and push.

The query

dependabot: "the property $.updates[0].allow has the wrong type" - schema validation failing the whole config

Use this when

• Dependabot reports a schema validation error mentioning $.updates[0].allow
• Dependabot stopped opening PRs after you edited dependabot.yml
• You copied an allow example from an old blog post or gist

Not for

• Dependabot update jobs failing mid-run (a resolver problem, not config)
• The ignore key (different key, different shape)
• Dependabot not supporting your ecosystem (a capability gap)

Steps

1. Look at the broken shape

sed -n '/mount the host path updates at container path /,/^[^ ]/p' .github/dependabot.yml | head -20

Expected output: you see the allow key with a flat list of strings underneath it. That is the shape the validator rejects.

2. Rewrite allow as a list of objects

Change this:

allow:
  - lodash
  - minimist

to this:

allow:
  - dependency-name: "lodash"
  - dependency-name: "minimist"

Expected output: each entry is a map with a dependency-name key. Quotes around the names are good hygiene.

3. Validate the file locally

Use a YAML parser plus dependabot's documented schema, or at minimum confirm the file parses and the updates entries have the expected keys.

python3 -c "import yaml,sys; d=yaml.safe_load(open('.github/dependabot.yml')); print(d['updates'][0]['allow'])"

Expected output: the allow value prints as a list of dicts, not a list of strings.

4. Push and watch the validation

Commit the fix and check the Dependabot logs or the repo's Dependabot tab for the schema error disappearing.

Expected output: no validation error, and dependabot resumes its schedule.

5. Confirm updates actually flow

Wait for the next scheduled run or trigger one, and confirm PRs open again. Verify: the allow list behaves as intended (only the named dependencies get updates).

Variant phrasings

dependabot allow wrong type schema validation

The short form, same fix.

dependabot.yml allow dependency-name list of objects

The shape-first search.

Compatibility: dependabot config file version 2. The object shape for allow has been required since the v2 schema.

Why it happens

The v2 config schema types allow as an array of objects so each entry can carry extra qualifiers like dependency-type. A bare string cannot carry those qualifiers, so the schema rejects it. Because the whole file fails validation, dependabot does not partially apply the config; one bad key disables everything, which is why PRs stop entirely instead of just ignoring the allow list.

Edge cases / pitfalls

• The error names updates[0], the first entry. Fix every updates entry, not just the first; the validator reports them one at a time.
• dependency-type accepts values like direct, indirect, production, development. If you only want direct dependencies updated, say so explicitly.
• Do not confuse allow with ignore. Allow restricts updates to the named set; ignore excludes from it. Using both on the same entry is contradictory.
• After fixing validation, check that the schedule did not silently skip runs while the config was broken. Trigger a manual run if the gap matters.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstXyDRnAREbhmidHYE6rLXA

Resolved from the public thread: https://vectle.com/posts/pstXyDRnAREbhmidHYE6rLXA

Thread query: dependabot: "the property $.updates[0].allow has the wrong type" - schema validation failing the whole config

TL;DR: The allow key under an updates entry must be a list of objects, each with a dependency-name (and optionally dependency-type), not a flat list of strings. The old flat-list shape fails schema validation and dependabot ignores the whole config file. Rewrite allow as a list of maps, validate the file, and push.