* feat(config-validator): validate object entries in the `repositories` array
* Allow global configs in the repository object entry
* Simplify tests by combining them
* Allow `enabled` inside the repository entry
* Address review feedback
* Align type with #43295
* Skip validation for 'repositories' key in global config arrays
* refactor: flatten repositories array validation nesting
Address review feedback by combining the isArray and key checks
to avoid an extra nesting level.
* fix(schema): allow object entries in repositories array
Align renovate-global-schema with runtime: entries may be a string or
an object with required `repository` plus full global/repo config.
* Revert "fix(schema): allow object entries in repositories array"
This reverts commit 9aca8dcde8.
* fixups
* fix(config/validation): handle `allowedEnv` and `allowedHeaders` in `repositories`
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
* test(config): ensure that `errors` and `warnings` are always checked
As a follow-up to 6e411730a0, we can make
sure that we have a linter rule to make sure that this is consistently
checked.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* test(config/validation): ensure we don't use length checks
As it hides the actual messages, and makes it harder to know what is
being checked.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: correct `onboardingConfig` example
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: correct `module.exports` syntax
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: completely skip `doc-fence-check` on code blocks only used for synatx highlighting
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: skip schema validation on non-config snippets
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* chore(tools/doc-fence-check): validate JSONC and Javascript code blocks
To further ensure that our documentation is well-formed, we can validate
that JSONC and Javascript code blocks are well-formed syntactically, and
are valid Renovate configuration.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* chore(tools/doc-fence-check): allow opting out of syntax validation
On top of schema validation wanting to be disabled, we should also
support disabling the syntax validation, in the case that we're using
`json` code blocks for syntax highlighting, but they're not necessarily
well-formed JSON.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: use `json` syntax highlighting
As `jsonc` doesn't seem to exist in Material for MkDocs.
As it's only for syntax highlighting, we need to opt out of validation.
* tsc
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
To prevent potential SSRF attempts, we can ignore a
misconfigured/malicious `next` link, and log a warning.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
To prevent potential SSRF attempts, we can ignore a
misconfigured/malicious `next` link, and log a warning.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
To prevent potential SSRF attempts, we can ignore a
misconfigured/malicious `next` link, and log a warning.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
To prevent potential SSRF attempts, we can ignore a
misconfigured/malicious `next` link, and log a warning.
For self-hosted users, we can provide an experimental override if they
need to opt back in.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As part of future changes, it would be useful to have a helper method to
handle the correct resolution for `Link` header parsing, where we want
to avoid the risk of a registry/platform providing a link to a different
hostname, which could lead to SSRF.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
* refactor(workers): allow extractedConstraints on PackageDependency
Mirror the existing PackageFileContent.extractedConstraints field on
PackageDependency so managers can attach per-dep constraints (e.g.
python_version markers from PEP 508 dependencies) without overloading
the user-facing constraints field. In fetch.ts these dep-level
constraints are merged on top of the file/global constraints before
lookup, so the most specific source wins while user packageRules can
still override afterwards.
Extracted from #42701 at the reviewer's request so the type-level
change can land independently of the pep621/poetry feature work that
consumes it.
* fix(workers): prefer configured constraints over extracted values
Preserve configured constraints when extraction provides values for
the same names.
User configuration must take precedence over metadata discovered during
package extraction so users retain control over dependency lookup
behavior.
---------
Co-authored-by: wwade <wwade@users.noreply.github.com>
As these have been out-of-sync with what is and is not currently
supported per our documentation.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
As a means to make it easier - in the future - to add new
`security:minimumReleaseAge*` presets, we can refactor the 2 mostly
duplicated presets into dynamically generated presets.
Although this is not quite a "rule of 3" scenario, this shape does look
consistent, and so we can perform an early refactor.
Although this should be like-for-like, we can release this as a `fix` to
get early feedback on whether it changes anything.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
* feat(presets): add `security:minimumReleaseAgeCrates` preset
This adds a three-day minimum release age for the `crate` datasource and preserves the existing exception for pin updates.
The preset is based on the existing `security:minimumReleaseAgeNpm` preset, with its exceptions limited to update types relevant to crates.io.
It accounts for the initial 72-hour crates.io deletion window and gives scanners time to identify malicious releases.
* fix(presets): scope crate release age by update type
This replaces the pin-specific override with one package rule for `major`, `minor`, and `patch` crate updates. It keeps updates without release timestamps out of the cooldown.
The focused tests cover included and excluded update types.
* fix(presets): warn about unsupported crate update types
This exempts lock file maintenance, replacement, and pin updates from the crate minimum release age policy. It adds PR body notes that explain why each update requires manual age validation.
* fix(presets): use singular crate release age name
This renames `security:minimumReleaseAgeCrates` to `security:minimumReleaseAgeCrate`. It aligns the preset with the `crate` datasource name before release.
* Update lib/config/presets/internal/security.preset.ts
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
---------
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
As noted in #44756, this would allow templates across Renovate's
different usages to be able to use the `renovateVersion` string as a
template variable.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As per #44820, `pinDigest` updates currently don't get
`minimumReleaseAge` checks applied to them.
We can extend the recent support for `digest`s being handled by also
introducing support for `pinDigest`s to receive `minimumReleaseAge`
enforcement.
This will:
- enforce `minimumReleaseAge` on all updates that `pinDigest`s has
pending
- consider the newest resolved version's timestamp, ignoring
`rangeStrategy`-related logic
- allow unversioned releases like `latest` to /not/ be bound by
`minimumReleaseAge`, as they'll potentially not have a release
timestamp and will be unpinned forever, which is less safe (and
reduces reproducibility)
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
updateLockedDependency() only searched the packages section of
composer.lock, so updates to packages-dev dependencies were never
recognized as already committed to the branch. Every Renovate run then
fell back to a full artifact update and rebuilt the branch from a clean
base, force-pushing grouped composer PRs containing dev dependencies
whenever the base branch had moved - even with identical content.
In some cases, we hadn't correctly wired in the `minimumReleaseAge`
checks for `digest`, due to the `currentValue` not changing.
To handle this, we need to:
- use our helper methods for calculating whether the `minimumReleaseAge`
has passed
- handle a new digest's new `releaseTimestamp`
the current timestamp
- intentionally not gate `minimumConfidence`, as this is only computed
per-release, not at the digest level
- note the fixed behaviour, and clarify when it will/will not work
- add coverage for all generated updates for `digest`s, including when
remapping a Go Modules update as a `digest`
- clarify that `filterInternalChecks` and
`applyMinimumReleaseAgeToDigestUpdate` should stay in sync
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
* chore(config): be explicit about `Renovate CLI` in `prFooter`
This was something I should have done in
72968d3726.
* fixup! chore(config): be explicit about `Renovate CLI` in `prFooter`
* fix(config-validator): warn when RE2 is not in use
Without RE2 the validator checks patterns with the JS RegExp engine, which
accepts syntax RE2 rejects, so configs can validate clean here and then be
rejected when Renovate runs.
Co-Authored-By: Claude (Opus 5) <noreply@anthropic.com>
* fix(config-validator): debug log for the RE2 opt-out
Setting RENOVATE_X_IGNORE_RE2 is deliberate, so it does not warrant a warning,
matching what the global worker already does.
Co-Authored-By: Claude (Opus 5) <noreply@anthropic.com>
---------
Co-authored-by: Claude (Opus 5) <noreply@anthropic.com>
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
renovate[bot]