agent's renovate config had a typo in 'versioning-strategy' — u

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

Add a packageRules entry matching the package name with allowedVersions set to a negated regex that rejects the unwanted suffix, e.g. a pattern excluding versions ending in -java7. Renovate then only proposes versions that pass the filter.

Steps

1. Add a packageRules entry matching the package name with allowedVersions set to a negated regex that rejects the unwanted suffix, e.g. a pattern excluding versions ending in -java7. Renovate then only proposes versions that pass the filter. The same allowedVersions mechanism works for any version-shape exclusion, like pre-release tags or vendor-specific classifiers you never want.

When to use

You are seeing this: The same allowedVersions mechanism works for any version-shape exclusion, like pre-release tags or vendor-specific classifiers you never want. Use this skill when you run into "Renovate: exclude unwanted version variants like -java7 builds".

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

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

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

Source: Stack Overflow #61211875 (accepted answer, 16 votes): Renovate proposes a -java7 variant of a Maven artifact while the project runs Java 8 and wants the plain release instead. The accepted answer shows the package-rule mechanism for filtering versions by pattern.

Verified resolution: Add a packageRules entry matching the package name with allowedVersions set to a negated regex that rejects the unwanted suffix, e.g. a pattern excluding versions ending in -java7. Renovate then only proposes versions that pass the filter. The same allowedVersions mechanism works for any version-shape exclusion, like pre-release tags or vendor-specific classifiers you never want.

Source URL: https://stackoverflow.com/questions/61211875/exclude-a-specific-version-pattern-in-renovate

Not specified by the original author.

TL;DR

The agent upgraded every package past the pins your project depends on. Restore packages.yml from git, delete package-lock.yml, re-run plain dbt deps to get the pinned versions back, and take --upgrade out of the agent's allowed commands.

Error

agent ran dbt deps --upgrade and broke the pinned dbt-utils version

Steps

1. Restore packages.yml from git: git checkout -- packages.yml (or revert the agent's commit). Expected: The pinned versions are back in the file.

2. Delete package-lock.yml so the upgraded resolutions do not linger. Expected: No lock file pointing at the upgraded versions.

3. Run plain dbt deps (no --upgrade) and then dbt compile. Expected: Pinned package versions install; the project compiles on the known-good set.

4. Remove --upgrade from what the agent may run; package upgrades become a deliberate human task with testing. Expected: Agents cannot upgrade packages unilaterally again.

When to use

• an agent ran dbt deps --upgrade and package versions moved
• macros from dbt-utils changed behavior after an agent run
• CI started failing after an agent touched packages

When not to use

• you intentionally upgraded packages (then fix the resulting breakage deliberately)
• the registry is down (that is connectivity, not --upgrade)
• a package version was yanked (repin to an existing version)

Tool compatibility

• git to restore packages.yml
• dbt deps without --upgrade respects pins
• package-lock.yml deletion to clear upgraded resolutions

Variant phrasings

agent upgraded dbt-core itself

Bigger blast radius: restore the environment (venv, container image) to the pinned dbt-core, not just packages.

upgrade broke only one macro's behavior

Pin that package tighter and override the macro in your macros/ dir if you need the old behavior while planning the upgrade.

Why it happens

--upgrade ignores your pins and takes the latest compatible everything, which is exactly what pins exist to prevent. Agents run it because a stale package caused some error and upgrading felt like fixing. Package upgrades need testing, not automation.

Edge cases

• If packages.yml had no pins (just package names), --upgrade changes nothing about your process but you still have no reproducibility; add pins.
• After restoring, diff dbt_modules against the lock to confirm the versions actually rolled back.

Provenance

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

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

Thread query: agent ran dbt deps --upgrade and broke the pinned dbt-utils version

TL;DR: The agent upgraded every package past the pins your project depends on. Restore packages.yml from git, delete package-lock.yml, re-run plain dbt deps to get the pinned versions back, and take --upgrade out of the agent's allowed commands.