* 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(manager/circleci): document YAML merge key parsing limitation
Signed-off-by: Ethan Setnik <esetnik@gmail.com>
* fix(manager/circleci): parse config files as YAML 1.1
CircleCI processes config files as YAML 1.1, but Renovate parsed them
as YAML 1.2. Configs that use YAML 1.1 features failed to parse and
the entire file was silently skipped, dropping every `docker` and `orb`
dep in it.
The most common trigger is a mapping with more than one `<<` merge key,
which YAML 1.2 rejects as a duplicate key. CircleCI's own processor
allows it, since merge keys are a YAML 1.1 feature.
Pass `{ version: '1.1' }` to `parseSingleYaml` so the parser matches
CircleCI's behavior, and add a regression test that covers the
duplicate-merge-key case.
Replaces the workaround note added in the previous commit on this
branch (per review feedback) — the config-side `%YAML 1.1` directive is
no longer needed.
---------
Signed-off-by: Ethan Setnik <esetnik@gmail.com>
* 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.
* feat(pip-compile): support --constraint alias and --overrides for uv
uv accepts both --constraint and --constraints (clap aliases) and
records the exact form used into lockfile headers. Only --constraints
was in the uv allowlist, so --constraint headers were rejected.
Similarly, uv supports --override/--overrides for version overrides,
but neither form was recognized by Renovate at all.
This commit:
- adds --constraint to uvOptionsWithArguments (value handler already
handles both forms)
- adds --override and --overrides to uvOptionsWithArguments with a
value handler that parses overridesFiles
- tracks override files as dependencies in the file graph (like
constraints) so lockfiles are recompiled when overrides change
- uses dotted mermaid edges for overrides (same as constraints)
Ref: https://github.com/renovatebot/renovate/discussions/39488
Co-authored-by: Cursor <cursoragent@cursor.com>
* test(pip-compile): add coverage for overrides dependency tracking
Add a test case in extract.spec.ts that exercises the overridesFiles
loop in extractAllPackageFiles, fixing the codecov/patch failure.
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
* feat(rust-toolchain): Implement `rust-toolchain` manager
* feat(rust-toolchain): Add support for legacy filename
* feat(rust-toolchain): Add support for legacy file format
* refactor(rust-toolchain): Reject empty `channel` strings at parse stage
* tests(rust-toolchain): Cover valid TOML missing `[toolchain]` or `channel`
* refactor(rust-toolchain): Log legacy format fallback at `trace` level
* refactor(rust-toolchain): Reject empty and multi-line legacy files explicitly
* tests(rust-toolchain): Cover unparseable channel value
* tests(rust-toolchain): Use `codeBlock` for multi-line fixtures
* docs(rust-toolchain): Scope pin example to `rust-toolchain` manager
Co-authored-by: Sergei Zharinov <1239644+zharinov@users.noreply.github.com>
* tests(rust-toolchain): Use `codeBlock` for schema fixtures too
---------
Co-authored-by: Sergei Zharinov <1239644+zharinov@users.noreply.github.com>
* feat(mise): add lock file support
- Add lockfile.ts with getLockFileName() for deriving lock file paths
- Add artifacts.ts with updateArtifacts() and updateLockedDependency()
- Add MiseLockFile Zod schema for parsing lock files
- Update extract.ts to be async and extract lockedVersion from lock files
- Export supportsLockFileMaintenance, lockFileNames, updateArtifacts, updateLockedDependency
* refactor(mise): remove redundant comments
Remove comments that simply restate what the code already clearly
communicates. Keep valuable comments that explain non-obvious behavior
(e.g., why temporary errors are rethrown) and move helpful examples
into JSDoc comments.
* fix(mise): improve lock file version lookup and add tests
- Fix lock file key lookup for non-registry tools (aqua:, ubi:, etc.)
Registry tools use short names (node), non-registry use full names
(aqua:cli/cli). New getLockedVersion() tries both patterns.
- Add injection prevention test for shell quoting
- Add update-failed test for error handling
- Add comprehensive tests for getLockedVersion()
- Add null check for depName in updateLockedDependency
- Add JSDoc to updateArtifacts and extractPackageFile
- Add lock file support documentation to README
- Remove code duplication by consolidating into lockfile.ts
* fix(mise): pass --local flag and MISE_ENV for env/local config files
When updating mise.local.toml, `mise lock` updates mise.lock, not
mise.local.lock. Add --local flag to target the correct lock file.
For env-specific configs (mise.test.toml), set MISE_ENV=test so mise
reads and locks the correct configuration.
Extracted getConfigType() from getLockFileName() to share the parsing
logic between lock file name derivation and command flag generation.
Builds on #42099 by altendky.
* test(mise): cover tool absent from lock file
* refactor(mise): remove dead branches in extractPackageFile
tools is required by MiseFile schema so if(tools) is always true.
depName is always set by createDependency so if(dep.depName) is always true.
Add test for tool absent from lock file to cover the lockedVersion
assignment branch.
* fix(mise): address review feedback on lock file support
* fix(mise): remove unsupported tool constraint
* fix(mise): add containerbase tool definition
* fix(mise): add typed exec constraint support
* fix(config): restore requireConfig typing
* test(mise): await registry extraction cases
* Update lib/modules/manager/mise/artifacts.ts
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* fix: revert unrelated types cleanup
* fix: drop missing VersioningName import
* fix(mise): use npm versioning string after import removal
* test(mise): set binarySource=global in artifacts spec
GlobalConfig.get now returns defaults; without explicit binarySource the
test fell into containerbase dynamic install and tried to resolve the
mise version via the github-releases datasource, causing missing HTTP
mock errors. Force binarySource=global so the spec only exercises the
mocked exec path.
---------
Co-authored-by: Kyle Altendorf <sda@fstab.net>
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
As a way of indicating how fresh our list of supported tools in the
registry is, we can make sure we populate the version into a note above
the table.
We can extract a type to make it easier to reference the parsed JSON
file.
This requires a small tweak to handle `content`'s table insertion.
The git-submodules extractor was setting sourceUrl to the raw git HTTP URL,
including the .git suffix (e.g. https://github.com/owner/repo.git).
This caused the 'githubDigestChangelogs' preset's changelogUrl template
'{{sourceUrl}}/compare/{{currentDigest}}..{{newDigest}}' to produce
invalid URLs like:
https://github.com/owner/repo.git/compare/abc123..def456
which 404s because GitHub compare URLs don't support the .git suffix.
Other managers (bundler, deps-edn, flux) already strip .git from sourceUrl.
This fix follows the same pattern.
* feat(manager/swift): support SSH URLs in Package.swift extraction and artifact matching
Swift packages can use SSH URLs (e.g. `git@github.com:owner/repo.git`) for
dependencies, but the Swift manager only supported HTTPS URLs. This caused
SSH-based dependencies to be silently ignored during extraction, and
Package.resolved pin matching to fail when protocols differed.
- Convert SCP-style SSH and `ssh://` URLs to HTTPS in `parseUrl()` using
the existing `getHttpUrl()` utility before platform detection
- Enhance `normalizeUrl()` in artifacts to use `parseGitUrl()` for
protocol-agnostic URL comparison (falls back to basic normalization
when parsed components are incomplete)
* test(manager/swift): add edge case tests to improve coverage
- Add test for unparseable SSH URL in extraction
- Add test for host-only URL fallback in artifact matching
* fix(manager/swift): remove redundant .git stripping in normalizeUrl
parseGitUrl() already strips the .git suffix from full_name,
so the additional regex replacement is unnecessary.
* test(manager/swift): add ssh:// protocol test for artifact matching
Cover the ssh://git@github.com/... URL format in addition to the
existing git@ SCP-style test for Package.resolved pin matching.
* refactor(manager/swift): use trimTrailingSlash helper in normalizeUrl
* refactor(manager/swift): always normalize URLs in parseUrl
* 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>
* test: ensure we set `binarySource=global`
As part of future changes, we'll correctly return the default value from
`GlobalConfig.get`, instead of `undefined` if no default is provided in
the `get` call.
As `binarySource=install` is the default, this then leads to these tests
failing, as they're intended to run with `binarySource=global`.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! test: ensure we set `binarySource=global`
* fixup! fixup! test: ensure we set `binarySource=global`
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* 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
* refactor(docs): don't use an `end` for autogenerated docs
As part of #42910, we wanted to avoid needing a "begin" and "end" to
each of our autogenerated docs replacements.
While looking into it, we're not actually using the "end" for anything,
so we can instead refactor this to be a single-line replacement.
To simplify the code and docs, we can remove this. At the point we need
this again, we can re-add the functionality.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! Merge remote-tracking branch 'origin/HEAD' into chore/no-replaceStop
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat(managers/maven): support `pom.template.xml` files
For users who are using templating for their POMs, we can parse them by
default, rather than requiring users explicitly add this to the
`managerFilePatterns`.
We can also add a test to validate the functionality.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! feat(managers/maven): support `pom.template.xml` files
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* 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.
* feat(manager/renovate-config): extract `constraints`
As noted in #41571, it would be useful to detect and suggest updates
when specifying `constraints` in Renovate config, where it's a known
tool we provide versioning information for.
We can extend our existing `renovate-config` manager to add support for
`constraints` that are known Containerbase tools.
We can support top-level `constraints` as well as `constraints` inside
`packageRules`.
* refactor(renovate-config): remove nesting
When a Go dependency uses a pseudo-version (v0.0.0-timestamp-hash) and
Renovate detects a newer pseudo-version, updateType is set to 'digest'
via the gomod special-case in lookup/index.ts. The digest update code
path was then writing only the 12-character bare commit hash, producing
invalid go.mod syntax:
- knative.dev/pkg v0.0.0-20250312035536-b7bbf4be5dbd
+ knative.dev/pkg 4a022ed9999a
Historical cause:
In 2018, the Go module proxy did not yet exist. Renovate queried the
GitHub API for the latest commit SHA and had no way to obtain the correct
commit timestamp, so it fabricated a pseudo-version using the wall-clock
time when Renovate ran. The result was syntactically valid but semantically
wrong. Go 1.11 and 1.12 did not validate pseudo-version timestamps, and
`go get` would normalise the fabricated version to the correct one anyway,
so this worked in practice.
Go 1.13 (2019) introduced strict pseudo-version timestamp validation,
rejecting any pseudo-version whose timestamp does not match the actual
commit time. Renovate's fix (31ce47297) was to drop the fabricated
timestamp entirely and write just the bare commit hash, then rely on
`go get` to expand it into a canonical pseudo-version. However, when
the `go get` command or other subsequent operations fail, Renovate may
leave the go.mod file containing dependencies pinned to bare commit hashes.
Why the fix is now safe:
Since the 2024 goproxy datasource changes, both newValue and newDigest are
extracted from the same proxy version string via pseudoVersionToRelease().
They always reference the same commit, so writing newValue directly produces
correct, syntactically valid go.mod output without depending on `go get` to
clean it up afterward.
Signed-off-by: Qixiang Wan <qwan@outlook.com>
* fix(poetry): perform deepmerge to fully enrich projectDep with info from poetryDep
previously, just additional `managerData` from the poetryDep was merged into the projectDep specification
* test(poetry): verify 'invalid-dependency-specification' if constraints specified twice
* feat(managers): rename `renovate-config-presets` to `renovate-config`
As part of future changes, we'll extend this support to cover other
functionality. Instead of having multiple managers for this
functionality, we'll use a single, shared, manager for all Renovate
config management.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! feat(managers): rename `renovate-config-presets` to `renovate-config`
---------
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>
As part of future changes in #42567 to surface the `constraints` of a
given Go module, we should first extract the constraints from the
package file.
To make this simpler for users, we can make sure we extract these at
parse time:
- the `toolchain` directive becomes the `golang` constraint, which
matches the `golang` tool name already in use for Containerbase
- the `go` directive becomes a new `%goMod` constraint, which keeps it
separate from the version of the Go toolchain actually used to run, as
well as clearly not for the Go tooling, or something that
Containerbase knows about
- we make sure to extract it with a SemVer range that can then be used
to ensure that, in future changes, using `constraintsFiltering=strict`
will allow filtering releases from the Go datasource based on this
constraint.
- because we're now returning the `constraintsVersioning`, we need to
make sure this is part of our types
* 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): add OCI protocol support for modules and providers
Adds support for Terraform modules and providers hosted in OCI-compatible
container registries using the `oci://` protocol.
Delegates OCI sources to Docker datasource for version resolution.
Supports both version in separate field and embedded in URL.
Closes https://github.com/renovatebot/renovate/discussions/38927
* refactor(terraform): address code review feedback for OCI support
cd - Move ociRefMatchRegex to shared location in base.ts
cd - Extract OCI parsing into parseOciRef function to reduce duplication
cd - Remove unnecessary registryUrls assignments
cd - Add skipReason when OCI tag is unspecified
cd - Inline oci.tf fixture to avoid triggering vulnerability scanners
cd - Refactor OCI regex tests to use it.each
* refactor(terraform): address PR review, round 2
- Replace custom ociRefMatchRegex/parseOciRef with getDep pattern,
reusing isOCIRegistry/removeOCIPrefix from helmv3/oci.ts
- Remove docs/development/oci-terraform-support.md
- Remove ociRefMatchRegex/parseOciRef from base.ts and modules.ts
- Simplify OCI test in extract.spec.ts
- Remove ociRefMatchRegex describe block from modules.spec.ts
* refactor(terraform): address PR review, round 3
extract duplicate function
Signed-off-by: Norman Stetter <85173861+norman-zon@users.noreply.github.com>
* fix: only allow valid oci urls
oci sources only support query params for versioning
* feat: pass through registryaliases
* fix: fix broken tests
* fix: address PR review round 4
* fix: replace new URL with parseUrl
Signed-off-by: Norman Stetter <85173861+norman-zon@users.noreply.github.com>
* fix: add tests for new path
Signed-off-by: Norman Stetter <85173861+norman-zon@users.noreply.github.com>
---------
Signed-off-by: Norman Stetter <85173861+norman-zon@users.noreply.github.com>
* feat: use poetry deps to enrich equivalent pep621/pep735 deps
* test: cover project.optional-dependencies in enrichment test
* refactor: replace reduce usage with for..of loop
* refactor: use nullish-coalescing during variable assignment
* refactor: use coerceArray helper instead of nullish coalescing
* feat(mise): automagically support all tools through Mise Registry
As noted in #42250, we should try and auto-support tools from Mise where
possible.
Similar to other areas of the codebase, we should use the "static data"
pattern, and periodically sync the `mise registry --json` output with
`lib/data/mise-registry.json`, and then auto-detect the tools that we
support through the known backends the tools support.
This takes lower precedence than existing in-code tool definitions, so
we can still provide an "override" if we can support lookups or version
extraction more appropriately.
Because we now have many more tools we (mostly) support out-of-the-box,
we need to provide an improved documentation page, and:
- only link to tools we have an explicit tools URL for
- note where a backend may not be supported
To automate the updating of this data, we:
- make sure we have `mise` in GitHub Actions, before we run
- don't pin the `mise` version to make sure that we're always seeing the
latest supported tools
- make sure the commits generated are now `feat(...)`, as they introduce
functionality changes (in the case new tool(s) are supported)
This improves support from ~170 tool short names to just over 1000.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor: use Typescript
As we can now, we should.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor(tools/static-data): use Zod schemas for parsing
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor(mise): use Zod for types
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* chore(mise): prefer the GitHub backend over other sources
As we generally prefer it as a project, we should automagically use that
when looking at a mise registry entry.
With help from GPT-4.1 to write the `sortBackend` function.
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* test: ignore else coverage
* docs(mise): preference of `github` backend
* docs(mise): auto-link autogenerated tools
* perf(mise): sort registry only once
* refactor(mise): transform when parsing
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* refactor: use `execa`
* perf(mise): read the Mise registry once
* perf(mise): pre-transform
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
Sebastian Poxhofer