pnpm v11.23 reshaped the `registries` setting in `pnpm-workspace.yaml`: it
is now keyed by the registry URL, with the scopes routed to it listed in the
entry. Renovate only accepted the older `<scope>: <url>` shape, so parsing of
the whole workspace file failed and its catalogs and overrides were no longer
extracted at all.
Accept both shapes and flatten the new one into the old one, where the bare
`@` scope is the scope-less default registry. URL keys which interpolate an
env var, embed credentials, or are unparseable are skipped, matching what
pnpm itself ignores or refuses. A `registries` value which is neither shape
now falls back to `undefined` instead of taking the file's catalogs with it.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
ci: tighten statements and functions thresholds
Both metrics have headroom against the current measured coverage
(statements 99.9899%, functions 99.9864%), so the floors can move up
without depending on any other pull request landing first.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
test(util): cover minimatchFilter and cachePathIsFile gaps
Brings lib/util to 100% coverage:
- minimatchFilter: the closure returned on the uncached path was never
invoked, and the options-based cache key branch was never taken
- cachePathIsFile: only the "does not exist" path was tested, so
stat().isFile() never ran
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* build(deps): update dependency @redis/client to v6
| datasource | package | from | to |
| ---------- | ------------- | ------ | ----- |
| npm | @redis/client | 5.12.1 | 6.2.1 |
* fix(cache): keep RESP 2 protocol with @redis/client v6
@redis/client v6 defaults to RESP 3, which requires Redis server 6.0 or
newer and changed the default type parameters, breaking the RedisClient
type alias. Pin RESP 2 explicitly and type the client accordingly. The
switch to RESP 3 is deferred to the next major release.
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: secustor <sebastian@poxhofer.at>
* feat(presets): vale package versions custom manager
Co-Authored-By: Claude Code
* fix(presets): fix lint and type errors in valeVersions tests
Co-Authored-By: Claude Code
* fix(presets): fix vale.ini file pattern to use regex delimiter syntax
Co-Authored-By: Claude Code
* test(presets): update valeVersions examples and add non-pinned case
Co-Authored-By: Claude Code
* feat(automerge): attempt branch automerge before falling back to a PR on merge queue rejection
* refactor(automerge): ask the platform instead of parsing merge queue rejection messages
* feat(gitlab): merge MRs through merge trains via the platform merge queue API
* feat(gitlab): report MRs waiting on a merge train through isPrInMergeQueue
* test(gitlab): drop targetBranch from mergePr calls
* Apply suggestion from @secustor
* refactor(gitlab): validate the merge train car response with a Zod schema
* feat(github): add experimental support for using merge queues without auto merge
* test(github): use vi.stubEnv for merge queue env flag
* fix(github): do not re-enqueue PRs already waiting in the merge queue
* refactor(github): reuse merge queue detection from #45252 for isBranchMergeQueueEnabled
* refactor(github): read the base branch from the PR instead of extending MergePRConfig
* feat(github): enable merge queue support without the RENOVATE_X_GITHUB_MERGE_QUEUE flag
* Apply suggestion from @secustor
* fix(merge-confidence): don't require auth in `platform=local`
When dry-running Renovate against a repository to validate it[0], if a
repository is using `matchConfidence`, the whole Renovate run is aborted
due to missing API credentials.
This can be frustrating, and the workaround available is to temporarily
remove all package rules use `matchConfidence`, which isn't the best
experience.
Instead, we should follow the existing pattern to return `null` when
loading a Package Rule with `matchConfidence`, as well as DEBUG logging
to inform the user why this is happening.
[0]: https://www.jvt.me/posts/2026/03/08/renovate-test-config/
* fixup! fix(merge-confidence): don't validate auth in a
With debugging from Claude to work out how to get the test to pass.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* feat(manager): share OCI Helm chart resolution across managers
Add getOciChartDep() to helmv3/oci.ts and use it in argocd, fleet, flux,
helmfile, helmsman, helmv3, kustomize, sveltos, terraform and vendir.
- set pinDigests: false for OCI charts in all of them
- apply registryAliases to OCI charts in argocd, helmfile and helmsman
- keep the registry port in terraform helm_release repositories
- skip fleet OCI charts without a version instead of using 'undefined'
* docs(manager/helmv3): correct the OCI chart pinDigests rationale
* refactor(manager/helmfile): drop redundant OCI repository url guard
The repository schema already requires url to be a string, so the falsy
branch could not be reached by parsed input and left the patch partially
covered.
As part of future changes, we're introducing a means to parse
Dockerfiles for any `apk add` commands, so we can propose updates to any
packages using the APK datasource.
Before we do this, we need to correct a couple of bugs in our
implementation of the APK versioning scheme, so we can handle i.e.
apk add curl=~8.12.1
When the `apk` CLI builds a version constraint, it `OR`s one flag per
operator character[0].
For instance, `~` sets both "fuzzy" and "equal".
These operator characters may be in any order and may repeat, so `~`,
`=~` and `~=` are all the same operator, and `>>` and `>` are the same.
To correct our parsing, we should take this into account, rather than
using known patterns.
When we perform a fuzzy match, this is performed over version _tokens_
not the version itself, which means that:
- `~1.6` matches `1.6`, `1.6.0_pre1`, `1.6.0`, `1.6.5` and `1.6.9_p1`
- `~1.6` does not match `1.60`
- `~8.12.1` matches every `8.12.1-rN` i.e. `8.12.1-r1` and `8.12.1-r100`
While doing this, we also fix related issues:
- `~` previously treated this as an npm-style tilde ("same major and
minor, and greater than or equal"),
- admitted fuzzy versions that `apk` rejects - `~2.39.0-r0` should not have
matched `2.39.1-r0`
- rejected fuzzy versions that `apk` accepts - `~2.39.0` should have
matched `2.39.0-r1`
- `=~` and `~=` were not allowed
- `isSingleVersion('=~1.2.3')` was true, so a range looked like a pin
- `isLessThanRange` compared against the raw range, so `_parse` failed on
the operator and it always returned false
- `minSatisfyingVersion` was inherited, so it only ever found an exact
match
- `getNewValue` dropped the operator entirely, rewriting `~8.12.1` to a
bare version
We also set `supportsRanges`, which we'd forgotten to set despite `~`
and `>=` being ranges, and note that we support `pin`, `replace` and
`bump` strategies.
When using `getNewValue`, we now keep the precision the constraint was
written with, as otherwise we'd quietly narrow what the user asked for:
- `~8.12.1` becomes `~8.13.0` (previously `~8.13.0-r0`)
- `~8.12` becomes `~8.13`
- `~8.12.1-r0` becomes `~8.13.0-r2` (with a new revision number)
For `bump`, we raise a lower bound which includes its boundary, as with
`npm` and `pep440`, so:
- `>=8.12.1` becomes `>=8.13.0`
- `>~8.12` becomes `>~8.13`
Otherwise we return `null`, logging which constraint we couldn't handle
in the `bump` case, as `npm` does:
- `>` on its own can't be bumped, as `>8.13.0` would exclude the version
we bump to
- `<` and `<=` are upper bounds, so there's no lower bound to raise
- for `replace`, there's no single obvious new bound for `<`, `<=`, `>`,
`>=`, `>~` or `<~`, and a bound which already admits the new version
doesn't need one
- a prefix constraint whose version doesn't parse, i.e. `~foo`, which
would otherwise throw
`><` constrains a package to an identity hash rather than to a version,
so it's rejected outright.
Additionally, `isLessThanRange` and `matches` weren't agreeing on how to
resolve a fuzzy constraint.
For instance, `_compare` ranks `2.39.0_git20240101` below `2.39.0`, but
`~2.39.0` matches it, this would lead to a rollback of sorts.
Instead, we can ignore the `_git` and `_p` suffixes, which are common in
Alpine and Wolfi packages.
[0]: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/44dcdfc255c26a4e19a4a27f66a54169cce5ca72/src/version.c
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
Michael Kriese