* fix(datasource): replace getJsonUnchecked with validated getJson in misc+merge-confidence group
Replaces all getJsonUnchecked calls with Zod-validated getJson calls in:
- crate: adds CrateMetadataSchema to existing schema.ts
- conan: uses existing ConanJSON schema directly
- puppet-forge: new schema.ts with PuppetModuleSchema
- conda: new schema.ts with CondaPackageSchema
- repology: new schema.ts with RepologyPackagesSchema
- jenkins-plugins: new schema.ts, parameterizes helper with ZodType<T>
- custom/formats/json: uses z.unknown() for user-defined responses
- merge-confidence: adds inline MergeConfidenceResponseSchema
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: correct nullable/optional schema fields for crate, jenkins-plugins, puppet-forge
- crate: remove .optional() from all CrateMetadata fields to match string|null type
- jenkins-plugins: use .default({}) instead of .optional() for plugins fields so schemas match required Record types; widen ZodType input to unknown; update JenkinsPluginVersion.releaseTimestamp to Timestamp|null to match MaybeTimestamp output
- puppet-forge: change releases from .optional() to .default([]) to match Release[] type
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* chore: migrate zod/v3 imports to zod/v4 in misc datasources and merge-confidence
Update remaining zod/v3 imports in files added/modified by the getJsonUnchecked
migration to use zod/v4 as required after the upstream migration.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* chore minor improvements
* remove unnecessary types and reintroduce nullable where necessary
* refactor: move logic into transform
* test: add tests to improve coverage
* chore removed some unused types
* remove type declaration
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(nuget): replace getJsonUnchecked with validated getJson
Migrate NuGet v3 datasource from unvalidated HTTP responses to Zod-schema
validated ones. Creates schema.ts with ServicesIndexRaw, CatalogPage, and
PackageRegistration schemas derived from the existing TypeScript interfaces.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(nuget): migrate zod import from v3 to v4
Update schema.ts to use 'zod/v4' instead of 'zod/v3' following the
upstream migration in renovatebot/renovate PR #43691.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* chore: some manual improvements
* refactor: rename schema
* fix linter errors
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(terraform-provider): replace getJsonUnchecked with validated getJson
Convert all five TypeScript interfaces (TerraformProviderVersions,
TerraformProviderReleaseBackend, TerraformRegistryVersions,
TerraformRegistryBuildResponse, VersionDetailResponse) to co-located
Zod schemas in schema.ts and update all five call sites in index.ts to
use the typed http.getJson() overload. Types are now derived with
z.infer<> to prevent interface/schema drift.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix linting errors
* remove types
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* docs: skip validation on JSON files that aren't Renovate config
As part of future changes, we'll enable validation on all JSON code
snippets to run Config Validation.
Before we do that, we should opt-out JSON snippets that aren't anything
related to Renovate config.
* docs: don't validate invalid Renovate config
As it's intentionally referencing a manager that doesn't exist.
* docs: don't validate partial Renovate config
As part of future changes, we'll enable validation on all JSON code
snippets to run Config Validation.
There are several code snippets we have that are part of a Renovate JSON,
but it doesn't make sense to convert these to a fully passing config, as
it'd reduce clarity on what we're trying to explain.
* docs: convert `baseBranchPatterns` snippets to code blocks
So we can validate them.
* docs: make sure that `datasourceTemplate` is set
So this passes validation.
* docs: clarify that `force` is global config
As it may not be clear, so we can make it extra clear with a `.js` file,
and note that it's global self-hosted config.
* docs: make sure `packageRules` is an array
* docs: `matchBaseBranches` needs `baseBranchPatterns` to be set
* docs: correct typo for `prBodyColumns`
* docs: mark global config snippets as such
As part of future changes, we'll use this to detect whether it's global
self-hosted configuration.
* docs: make sure `packageRules` wraps its children
* docs: add `allowedHeaders`
* docs: ignore deprecation warnings
As part of future changes, we'll use this to note that we don't care
about the validation warnings.
* docs: make sure `customManagers` wraps its children
* docs: make sure `fleet` wraps its children
* docs: validate JSON snippets are valid Renovate config
To make sure that we're always presenting valid JSON configuration to
our users, we can validate them as part of `check-fenced-code`.
As well as configuration errors we can warn for warnings, but allow code
blocks to opt-out, for instance when there's a known deprecation
affecting the code block.
We need to make sure to set `allowedEnv` for various code snippets that
reference environment variables.
* docs(development): document fenced code block checks
* docs: wrap `configType` and `ignoreConfigWarnings` in `{ ... }`
As otherwise we see build failures i.e.
WARNING - Doc file 'modules/platform/gitlab/index.md' contains a link
'../../../self-hosted-configuration.md#autodiscoverrepoorder', but the doc
'self-hosted-configuration.md' does not contain an anchor '#autodiscoverrepoorder'.
This needs to be wrapped alongside all other options like `title`.
* fixup! docs: wrap `configType` and `ignoreConfigWarnings` in `{ ... }`
* chore: migrate from zod/v3 to zod/v4
This commit contains the logic changes
* chore: migrate imports from zod/v3 to zod/v4
This contains import updates and adds explicit record keys as zod/v4 requires these now
* ci: enforce usage of zod/v4
* ci: add local mkdocs-admonitions plugin for prettier to allow admonition preservation
* docs: remove uses of `prettier-ignore` for admonitions
* test: rather use await expect
* chore: use named group exclusively
* docs: ensure 2 spaces used for generated admonitions
As a follow-up to 4b0146ab7b and
1844916259b6dc17f532e491eb93f6116327c324., this correctly renders
admonitions with 2 spaces (1 indent).
* fixup! docs: use 2-space indentation for Markdown (#43537)
Plus using 3-space for mixed-style `<ul>` and `<ol>`s.
* fixup! docs: use 2-space indentation for Markdown (#43537)
As otherwise it breaks the rendering of the table.
* feat(datasource/github-runners): stabilize arm64
Mark the Ubuntu ARM runners as stable.
* feat(datasource/github-runners): add test
Add test for upgrading ubuntu-22.04-arm runners.
* feat(datasource/github-runners): add windows-11-arm label
Add support for Windows 11 ARM runners in the GitHub Runners datasource.
* feat(datasource/github-runners): add test
Add test for extracting windows-11-arm runners.
* feat(datasource/github-runners): fix test
Update expected length.
* fix(datasource/rust-version): skip blank lines in manifests.txt
`https://static.rust-lang.org/manifests.txt` ends with a trailing
newline, so `response.body.split('\n')` always yields an empty final
element. `parseManifestUrl('')` returns `null`, which triggered the
`Failed to parse manifest URL` warning on every run. The warning then
surfaces as a `Repository Problems` entry on the Dependency Dashboard
for any repo with a rust-version-tracked dep (`rust-toolchain.toml`,
or a custom-regex manager pointing at the `rust-version` datasource).
Skip blank/whitespace-only lines silently; keep warning on genuinely
malformed non-empty lines (covered by the existing
"ignores unexpected URLs" test).
* docs(datasource): condense comment
Co-authored-by: RahulGautamSingh <rahultesnik@gmail.com>
* Remove accidental newline
---------
Co-authored-by: RahulGautamSingh <rahultesnik@gmail.com>
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
As noted in #43445, there are cases where:
- an infrequently updated repository prepares a GitHub Release by
creating a draft release
- some time passes, and the maintainers publish the Release
- no new commits are pushed to the release branch (i.e. `main`) in that
time
In this case, Renovate would previously use the `created_at` of the Git
tag (according to the GitHub API) rather than the `published_at` time
from the GitHub Release.
This is correct when using a plain Git tag, as we only have metadata to
indicate when the commit the tag points to was created.
However, when we have GitHub Release information, we should use that to
take precedence.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
In 01bcd4fd43 we introduced knowledge of
the Maven Central mirror, but haven't taken it into account when looking
at rate limit errors.
To prevent this in the future, we can introduce a new helper function,
`isMavenCentral`, for other usage.
* fix(datasource/maven): cache 404s on `maven-metadata.xml` for 24h
As part of efforts to reduce the general overload on Maven Central[0]
from Renovate, we can look to reduce unnecessary HTTP lookups.
The Maven Datasource will use the `registryStrategy=merge`, which leads
to looking up a package in each of our registries, and merging them if
present.
However, this means that when looking up a package that /will only ever
be in a given registry/ (such as in
01bcd4fd43) we're hitting other registries
with packages they are unlikely to have.
This is unnecessary, significantly increases traffic to Maven Central,
and leads to us re-fetching the same 404s which count towards rate
limits, and increased, unnecessary, server load on Maven Central.
We can instead introduce a new cache for 404s for the
`maven-metadata.xml`, for 24 hours, which should reduce traffic to Maven
Central (and other configured registries) if they only have a subset of
dependencies.
[0]: https://www.sonatype.com/blog/maven-central-and-the-tragedy-of-the-commons
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! fix(datasource/maven): cache 404s on `maven-metadata.xml` for 24h
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* cache-down
* perf(datasource/maven): add jitter
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* sq
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
fix(datasource/maven): cache `.pom` URLs for 7 days
As part of efforts to reduce the general overload on Maven Central[0]
from Renovate, we can look to reduce unnecessary HTTP lookups.
For instance, when a `.pom` URL is retrieved, it is re-checked every 15
minutes in case it has been updated.
This is unnecessary, significantly increases traffic to Maven Central,
and leads to us re-checking constantly for artifacts that are not
updating.
Each time we perform the lookup, we'll use the ETag result to do an
`If-None-Match`, but this still introduces an HTTP call upstream that
counts towards rate limits, and server load on Maven Central.
Instead, we can wrap the lookups for immutable pom.xml results with a 28
day soft cache. In a rare case where a `.pom` URL is updated, we'll then
re-fetch it after 28 days, but until then, it'll be safely returned from
cache.
[0]: https://www.sonatype.com/blog/maven-central-and-the-tragedy-of-the-commons
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fix(config/global): return default values for `GlobalConfig.get`
As noted in #39949, it can be awkward working with in `GlobalConfig.get`, where
we would previously need to specify the default value when calling `.get`,
which could lead to drift with the defaults for a given config option.
To reduce this risk, we can rely on a given `default` for a configuration
option, providing that as a default.
Because this now definitely returns a value that matches the config option, it
now allows us to remove `!` assertions.
* fixup! fix(config/global): return default values for `GlobalConfig.get`
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
* fixup! fix(config/global): return default values for `GlobalConfig.get`
* test(presets): remove impossible test
As it's now not possible to set a value as `undefined` (as
`GlobalConfig` will then use the default), this test no longer validates
anything.
* test(workers/repository): add mock
Now `platform` defaults to `github`, we need to mock out the call to
fetch config.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* test: coverage
* test: coverage
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs: add inline JSDoc for `RegistryStrategy`
Noticed while making other changes, that it wasn't clear looking at the
type what these values meant.
We can use a `@see` annotation to move the inline documentation from the
`DatasourceApi` to use our source-of-truth.
* docs: update `RegistryStrategy` docs in line with implementation
With help from Claude Sonnet to derive more information from the
implementation.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fix(datasource/maven): don't look up potential Gradle Plugins in Maven Central
As part of efforts to reduce the general overload on Maven Central[0]
from Renovate, we can look to avoid lookups that we know are likely to
never resolve.
For instance, via #43146, we can skip any packages that appear to be a
Gradle Plugin, as they will only ever be sourced from the Gradle Plugin
Portal.
[0]: https://www.sonatype.com/blog/maven-central-and-the-tragedy-of-the-commons
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* Update lib/modules/datasource/maven/readme.md
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* test(noNewURL): add new rule enforcing parseUrl() from 'lib/util/url.ts'
* replace newURL with parseUrl
* remove non-null assertions marks if appropiate
* test: add additional tests
* test: add additional tests and ignore where it makes sense
* implement suggestions
* test: further improve coverage
* apply suggestion
* central function for creating SimpleGit instance
* Updated tests.
* Set the LANG and LC_ALL environment variables for all Git operations instead of just initRepo.
* Moved GIT_SSH_COMMAND to `createSimpleGit` function.
* Removed unnecessary custom env vars.
When running Renovate in a shared environment, such as Mend-hosted
Renovate, if relying on the new functionality for `constraintsFiltering`
checks in the Go datasource, it's possible to get data without
the `constraints` embedded in them.
This is due to us using a cache key that doesn't take into account
whether we are `constraintsFiltering`, which controls whether we look up
the `go` directive for a given Go module.
We can fix this by introducing an additional entry into the cache key
for the `constraintsFiltering` value.
We can make sure that this doesn't modify existing
(non-`constraintsFiltering`) entries, and only add additional keys if
`constraintsFiltering` is set to something other than the default.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat(datasource/go): conditionally expose `constraints`
As noted in #42567, some Go modules are constrained by their
compatibility with the source compatibility with the Go language as per
the `go` directive.
Bumping the `go` directive will result in all of a library's consumers
also needing to bump their own `go`, which can be something library
authors will attempt to avoid.
Previously, Renovate users would receive an update from any modules that
have a new release, regardless of whether they will bump the `go`
directive.
With this change, users who use `constraintsFiltering=strict` will have
the filtering applied, so they only receive updates for Go modules in
their current minor version.
Due to the additional API calls needed, this is an opt-in feature, and
only includes the API calls when the using
`constraintsFiltering=strict`.
We can also add an integration test to build our confidence in the
end-to-end flow.
* fix(datasource/go): correctly check Go directive for major version bumps
As we weren't passing around the `pkg` (which included the Semantic
Module Import Path), we were incorrectly lacking major version upgrades.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* chore: remove `fallback`
As it's unnecessary.
* docs(gomod): rephrase
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat: allow separate versioning for constraints
As noted in #31831, there are times where it can be useful to override
the version that a given datasource uses, when performing
`constraintsFiltering=strict.`
This should only be applicable to the "additional" constraints, so we
make sure to validate this.
As this is new functionality, any misconfiguration should be marked as
an error.
We can make sure to provide a real-world usecase for this (taking
inspiration from `rails`' versioning of the `rubygems` constraint).
This will be used in the future by the extraction of the `go` directive,
which requires a different versioning to the default `semver`.
* fixup! feat: allow separate versioning for constraints
* fixup! feat: allow separate versioning for constraints
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* extra-log-context
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat(terraform-provider): add zod schemas for v2 API response
* feat(terraform-provider): use registry v2 API for release timestamps
* feat(terraform-provider): add zod schema for OpenTofu API response
* feat(terraform-provider): add OpenTofu registry docs API support
* feat(terraform-provider): update v2 API response handling and schema validation
* feat(terraform-provider): use schema transform for OpenTofu response
* fix(terraform-provider): address PR review feedback for OpenTofu support
* fix(terraform-provider): resolve sourceUrl from OpenTofu version details
* fix(terraform-provider): derive OpenTofu sourceUrl from registry naming policy
* feat(datasource/npm): extract defaultRegistryUrl constant
* Fix some other places
* Remove useless defaultRegistryUrls export
* Fix another place
* Undo rules.spec.ts changes, which are not related
* Fix npm presets
* Restore line removed by mistake
* Fix another test file
* Restore changes to a file which is not relevant
* Fix another small place
* chore(datasource): add missing parentheses
* fix(datasource): handle both config and release constraints as a range
In the case that the user's config is a range, but the release itself
provides an exact value for the constraint, we currently do not
correctly filter it.
Sebastian Poxhofer