* test(workers/lookup): cover the remaining generateUpdate branches
Adds a unit spec for `generateUpdate()` exercising the branches that the
surrounding lookup tests never reached: a release carrying `checksumUrl`,
`downloadUrl` and `newDigest`, a versioning api whose `getNewValue`
throws, and an update with no current version.
With those covered, the last istanbul ignores in the file can go, so
`generate.ts` now reports full statement and branch coverage with
nothing suppressed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(workers/lookup): cover two untested lookup branches
Adds tests for two paths flagged by the `TODO: add test #40625` markers
that no existing test reached:
- `filterInternalChecks()` with a release that has no `releaseTimestamp`
while `minimumReleaseAgeBehaviour` is unset. The existing tests only
cover `timestamp-required` and `timestamp-optional`, so the release is
now checked to be accepted without being reported under either.
- `lookupUpdates()` when no current version can be resolved but a
`lockedVersion` is set, which must return without marking the
dependency `invalid-value`.
The ignore comments are left in place, so these branches stay excluded
from the coverage report; each test instead asserts an outcome that only
holds on the intended path.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(workers/lookup): cover error paths in bucket, current and rollback
Adds unit specs for three exported helpers whose guard clauses no test
reached: `getBucket()` when the versioning api cannot determine a major
or a minor, `getCurrentVersion()` when the current value is not a string,
and `getRollbackUpdate()` when the versioning api lacks
`isLessThanRange()`, when `isLessThanRange()` throws, and when there is
nothing older to roll back to.
The ignore comments on those branches are left in place, so the coverage
report is unchanged; each test asserts the return value that is only
produced by the guard it targets.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(workers/lookup): cover filter and rollback guards
Covers three more guards that no test reached: `filterVersions()` with
no current version, and `filterByMaxMajorIncrement()` when the versioning
api cannot determine the current major or a release's major. Adds a
`lookupUpdates()` test for the case where rollbacks are enabled but
nothing older exists to roll back to, which warns instead of updating.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(workers/lookup): cover the vulnerability alert range strategy fallback
A vulnerability alert configured with `rangeStrategy=update-lockfile` but
no locked version falls back to `bump`, which no test covered. The new
test asserts the range is widened and the update is marked as a bump,
which only happens once the fallback has been applied.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs(workers/lookup): explain the remaining coverage ignores
Each ignore left under `lookup/` now records why the branch it hides is
not reached, instead of pointing at a TODO with no detail. No ignore is
added or removed, and the coverage report is unchanged.
The explanation goes above the hint rather than after it: a hint only
applies to the statement on the line immediately below, so trailing
comment lines silently stop it from suppressing anything.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(workers/lookup): cover three more unreached lookup branches
Covers the guards behind three of the remaining ignore hints:
- `getRollbackUpdate()` when the release it falls back to carries an
empty version, so there is nothing to roll back to after all
- `filterVersions()` coercing a release version that the configured
versioning accepts but semver cannot parse, which happens once
`allowedVersions` falls back to semver range syntax
- `lookupUpdates()` when the datasource rejects every candidate release
during postprocessing, leaving a bucket with no release to update to
The ignore comments stay in place, so the coverage report is unchanged;
each test asserts an outcome that only holds on the intended path.
Co-Authored-By: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* docs(workers/lookup): correct the ignore reasons this branch disproves
Three of the reasons added alongside the previous batch of tests claimed
their branch was unreachable, which the tests in this branch disprove:
`getRollbackUpdate()` can pop a versionless release, `filterVersions()`
does coerce a version semver cannot parse, and `filterInternalChecks()`
yields no release when a datasource rejects every candidate. Each now
describes what actually reaches it.
Also sharpens two of the reasons that still stand. The `getBucket()`
else contradicts the `isVersion()` filter every release has already
passed, so it reads as unreachable rather than untested; and a lookup
whose releases are all unversioned tags never reaches the empty-version
block, because a configured digest routes it to the digest-only path
first.
No ignore is added or removed, and the coverage report is unchanged.
Co-Authored-By: Claude Opus 5 <michael.kriese+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
Vitest uses the v8 coverage provider, and v8-to-istanbul still honours
istanbul hints, so these comments suppress real branch coverage rather
than being inert. The `releaseTimestamp` and `registryUrl` branches are
both exercised by the existing lookup tests, so their ignores only hid
coverage that was already there.
The remaining ignores in this file stay: no datasource used in these
tests reports a checksum url, and the `getNewValue` catch block and the
missing-currentVersion guard are still unreachable.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(manager): pass extracted constraints to updateArtifacts
`extractedConstraints` were collected during extraction but only ever read
by `fetch.ts` for the lookup. At artifact time every manager had to derive
the same tool constraints a second time, and when the updated package file
no longer carried the constraint there was nothing to fall back to.
`generateBranchConfig()` now merges the `extractedConstraints` of all
upgrades of a branch onto the branch config, which reaches `updateArtifacts()`
through `patchConfigForArtifactsUpdate()`. `UpdateArtifactsConfig` declares
the field and documents what it contains.
The new `resolveToolConstraint()` helper implements the ladder once:
user `constraints` > an optional artifact-time derivation > the extracted
value. The derivation is ranked above the extracted value on purpose: it
reads the package files as the branch changed them, so poetry (python is an
updatable dependency there), composer, pipenv (`pipenv` can be a dev
package) and pep621 (`requires-python` is an updatable dependency) would
otherwise regress to a stale constraint. pipenv, pep621 uv/pdm, poetry and
composer are migrated to the helper and keep their derivation.
Behaviour change: these managers now use the extract-time constraint as a
last resort instead of running unconstrained, for example on lock file
maintenance where pipenv deletes `Pipfile.lock` before deriving.
`execute-post-upgrade-commands.ts` is unaffected: it reads
`upgrade.constraints` per upgrade, and the extracted values are kept in a
separate field rather than folded into `constraints`, so post-upgrade task
tool constraints still come from user config only.
Not migrated, because their constraints are never extracted, so the
fallback would be dead code: bundler (`ruby`/`bundler`), pixi (`pixi`),
pep621 uv (`required-version`) and npm's node ladder, whose last step
already reads `package.json` engines.
* refactor(manager): resolve tool constraints through resolveToolConstraint()
Every manager now obtains the constraint of a tool it runs through
`resolveToolConstraint()` instead of reading `config.constraints` itself, so
the precedence "user config, then a value derived from the updated files, then
the constraints collected during extraction" applies everywhere. The helper
treats an empty string as not set at every step and accepts the
`PostUpdateConfig` shape, whose `constraints` may be `null`.
Behaviour changes that go beyond the new fallback to extracted constraints:
- `mix` applies its hardcoded erlang default only after the extracted
constraint, so an erlang version collected at extraction can win over it.
- `kustomize` decides `HELM_EXPERIMENTAL_OCI` from the fully resolved helm
constraint; `generateHelmEnvs()` takes that value instead of the config.
- `npm` (yarn): an upgrade of yarn without a new value now consults the user
constraint before deriving one from package.json or the lock file.
- The "Using <tool> constraint from config" debug lines in bundler, composer,
copier and pip-compile are gone, as the helper is the only reader of the
config now.
Helpers that read the config synchronously became async: bundler
`getBundlerConstraint()`, copier `getPythonVersionConstraint()` and
`getCopierVersionConstraint()`, pip-compile `get*VersionConstraint()` and
`getToolVersionConstraint()`, gomod `deriveGoToolchainConstraints()` and
`getUpdateImportPathCmds()`, mise `getMiseLockToolConstraints()`. composer
`getPhpConstraint()` is removed.
Each converted manager has a test showing the extracted constraint reaching
the executed tool, and, where a derive callback exists, that the derived value
still wins over it.
* refactor(linters): add prefer-resolve-tool-constraint rule
Reports member reads and destructuring of `constraints` and
`extractedConstraints` from a manager config in `lib/modules/manager/**`, so
that tool constraints are resolved through `resolveToolConstraint()` in
`lib/modules/manager/util.ts` only. Writes and the same properties on package
files, which extraction has to populate, are not reported. The helper itself
and spec files are exempt in `.oxlintrc.json`.
* refactor(manager): inline thin resolveToolConstraint wrappers
Drop copier/utils.ts and the pip-compile getPipToolsVersionConstraint /
getUvVersionConstraint helpers, which only forwarded to
resolveToolConstraint(). Callers now call it directly.
* docs(development): note lock file maintenance in tool constraints section
* refactor(manager): address review on tool constraint resolution
composer only runs extractConstraints() when a user constraint is missing,
via Lazy. UpdateArtifactsConfig no longer re-declares constraints and
extractedConstraints, which ToolConstraintsConfig already provides.
* refactor(lookup): remove redundant currentValue check
The inner `if (config.currentValue)` was already guaranteed by the
enclosing condition, so the `v8 ignore else` comment was hiding an
unreachable branch rather than an untested one. Drop both; the
`invalid-value` path remains fully covered by existing tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Update lib/workers/repository/process/lookup/index.ts
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
* refactor(lookup): use safeStringify for invalid currentValue log
Template interpolation of a non-string `currentValue` yields
`[object Object]`, which hides the value that made it invalid. Use
`safeStringify` so objects and arrays are logged readably.
Co-Authored-By: Claude Opus 5 <michael.kriese+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* refactor(platform): share one implementation between gitea and forgejo
The `forgejo` platform was copied from `gitea` in #37075 and the two have
drifted since: fixes landed on one side only (zod validation #43900, empty
email #44068, null issues #44048, team reviewers #39533, merge-style fallback
#37768 vs #38040), and lint sweeps had to be applied to both copies by hand.
Both platforms now build on `lib/modules/platform/gitea-common/`, which holds
the zod schemas, API helpers, utils, PR cache and the platform object itself.
`createPlatform()` closes over its own state, so `gitea` and `forgejo` keep
separate config, caches and host types. `gitea/index.ts` and `forgejo/index.ts`
are thin wrappers that supply the platform id, default endpoint, http client
and the version gates that genuinely differ.
Reconciliations, forgejo's behaviour adopted for gitea:
- Responses are validated with zod instead of `getJsonUnchecked` casts. Gitea
therefore tolerates empty emails, null PRs in list responses and lenient
repo/issue payloads the same way Forgejo already did.
- `getRepoContents` returns a discriminated union, so `getRawFile` returns null
for dir/symlink/submodule entries instead of reading a missing field. The
gitea preset resolver now throws PRESET_INVALID for non-file entries, like
the forgejo one.
- An unknown `default_merge_style` (e.g. `manually-merged`) is caught by the
schema and skipped, instead of aborting the repository with
REPOSITORY_BLOCKED from `isAllowed()`.
- `initRepo()` resolves whether the repo owner is an org and only fetches org
labels when it is, adding one `/orgs/{owner}` request and an `orgs` entry in
the gitea repository cache.
- Reviewers prefixed with `team:` are sent as `team_reviewers`. Gitea keeps its
`v1.14.0` guard for requesting reviewers at all.
- `getBranchStatusCheck()` maps unknown commit status values through the
schema's `unknown` fallback rather than warning and returning yellow.
Gitea's behaviour is kept where it is deliberately different: the Forgejo
instance detection and its deprecation notice, the `1.24.0` (or `10.0.0` for a
detected Forgejo) native automerge gate, and the reviewer version guard are
passed in as options.
Two shared log messages became static so they can be grouped in metrics:
`{platform}-native automerge: fail` is now `Platform-native automerge: fail`
and `{Platform} getRepos() error` is now `Error auto-discovering repositories`,
both with the platform id in the metadata. The dead `defaults.hostType` field
is gone.
* refactor(platform): keep the shared gitea implementation under gitea/
Drop the `gitea-common/` folder. The zod schemas, API helpers, utils, PR
cache and `createPlatform()` live in `lib/modules/platform/gitea/` under
their original file names, and `forgejo/` imports them from there.
The preset resolvers pass `giteaHttp` and `forgejoHttp` to
`getRepoContents()` directly, which removes the two bound wrappers. The
gitea changelog source uses the shared `RepoContents` type like the
forgejo one already does.
* refactor(http): derive ForgejoHttp from GiteaHttp
The two clients were identical apart from the default `hostType`.
`ForgejoHttp` now extends `GiteaHttp` and only keeps its own base url,
so the pagination logic exists once. The platform helpers accept
`GiteaHttp` directly instead of the `HttpBase` alias.
Also covers the `updatePr()` branch where the updated pull request
cannot be converted and therefore is not cached.
* refactor(platform): create the gitea and forgejo http clients in index.ts
`forgejo-helper.ts` only held the `ForgejoHttp` instance, so it is gone
and `forgejo/index.ts` creates the client next to the platform. Gitea
does the same for symmetry, which leaves `gitea-helper.ts` with only the
shared API helpers.
* refactor(platform): fetch gitea labels and issues with await
`getLabelList()` and `getIssueList()` still memoize the in-flight
promise, but build it from small async functions instead of `.then()`
and `.catch()` chains.
* refactor(platform): keep declaration order of gitea/index.ts
Order the module the way it was before `createPlatform()` so the diff
against main aligns: platform id and http client after the repo config
interface, pure helpers before the factory, and `maxBodyLength()` after
the platform object.
* refactor(platform): move gitea label fetching to labels.ts
`fetchLabelList()` takes the http client and the repository details
instead of closing over the platform state, and gets its own spec. The
factory only keeps the memoizing `getLabelList()`.
* refactor(platform): move gitea label lookup to labels.ts
* refactor(platform): create the gitea pr cache per platform
`GiteaPrCache` is now created once per platform with its http client and
platform id, and `initRepo()` records the repository. The per-repository
state moves to a private `RepoPrCache` which is bound to the repository
cache on first use and reused until the next `initRepo()`, instead of
being rebuilt on every lookup.
fix(dashboard): keep abandoned note outside the <details> block
GitHub only renders alert callouts at the top level of a body, not
inside collapsible <details> sections. Move the abandoned-dependencies
note above the details block so it renders as a styled note.
* added support for extracting integrity and tarball from npm datasource
* test(datasource/npm): keep integrity and tarball in packument shape assertions
The packument-trimming tests on main pinned a cached shape that dropped
`dist.tarball`, so they broke once the schema started retaining
`integrity` and `tarball`. Update both expectations to the new shape and
cover `integrity` alongside `tarball`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(workers/lookup): expect integrity and tarball on npm updates
`generateUpdate` copies `downloadUrl` and `newDigest` from the release
onto the update, so every npm lookup in these tests now carries the
tarball URL and, where the packument fixture has one, the integrity
hash. Pin and rollback updates are built without those release fields,
so their expectations are unchanged.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Michael Kriese <michael.kriese@mend.io>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(datasource/gitlab-tags): replace getJsonUnchecked with validated getJson
The go datasource embeds GitlabTagsDatasource, so its test mocks are
updated to satisfy the stricter GitlabTag schema (commit.id/created_at).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* test: fixup tests
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Renovate deployments that are deployed across multiple organisations may
take advantage of Inherited Config as a means to decentralise some
decisions and/or preferences that their organisations would like to use
for some self-hosted configuration.
Similarly, the decision of which hosts to allowlist may be something
that a self-hosted administrator /may/ want to allow their organisation
admins to decide.
We can make this an opt-in capability to indicate that the self-hosted
administrator trusts the Inherited Config moreso, and allows someone who
can write to it the ability to allowlist access to internal hosts that
may not be intended.
If a self-hosted administrator sets `allowInternal: false`, this takes
precedence, allowing a "veto", and a self-hosted admin's `headers` are
still preferred, too.
It's not possible for Inherited Config to set grants for `extends`, as
config resolution has already occurred, so this still needs to be
performed at the self-hosted config level.
This trust is transitive: `hostRules` defined in presets the
inherited config `extends` are registered at the same inherited
tier once resolved, so this option must only be enabled when those
preset sources are trusted too.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
Indirectly related to our changes to Host Rules, it was noticed that we
previously did not provide as helpful an error when a config validation
error occurs with Inherited Config.
Instead of throwing a `CONFIG_VALIDATION`, without a `validationSource`,
`validationError` or `validationMessage`, we can instead throw it
accordingly.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
With the new hardening on blocking internal hosts with outbound HTTP
calls, we should build on top of this to ensure that the UX is better
when a preset is blocked.
We can do this by making sure that when `HOST_BLOCKED`, we report a more
targeted config validation error.
We can also make sure to pass around our `internalGrants`, similar to
how we currently allow an admin's `headers` are handled.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
As part of follow-up changes, we're looking to tighten the way that
Renovate handles outgoing HTTP traffic.
Before we do this, we can introduce a new config option,
`hostRules[].allowInternal`, that allows a self-hosted administrator to
mark an internal host as "trusted" for access.
This wires in the new global-only config option, `allowInternal`, which
implies a new internal field `internalHostGrant`.
We'll add full documentation in a future commit, when the full
enforcement is in place, as there are some wider changes to enforce it
fully.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
* feat(config): add experimental exitCodeForErrors option
* feat(config): give unknown-error its own exit code
* docs: restore exit codes 1 and 2 to the table
* 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(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
For instance, when a repository is onboarding with many dependency
updates (some of which have many security releases), it would be
useful to let the user know that they're not unlimited, but that the
rate limit is taken into account.
Now we have the capability to specify these, we should:
- take them into account when determining how many PR(s) may be raised
at a given time
- point users to the documentation when they may want to limit them, if
the number of security PRs is more than the
`prConcurrentLimit`/`branchConcurrentLimit`
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* test(core): replace file snapshots with explicit assertions
* test(core): replace inline snapshots with explicit assertions
* test(core): assert on relevant sections instead of full bodies
* test(core): drop assertions implied by full equality
* test(core): address review feedback
* test(core): use resolves instead of awaiting inside expect
* fix(bump-versions): collect bumpVersions from all upgrades, not just upgrades[0]
* chore: add test for duplicate bumpversion configs
* chore: use suggested safeStringify
* chore: use coerceArray
* test: validate minimumReleaseAge does not apply to security updates
* test: add end-to-end coverage for security-update minimumReleaseAge bypass
Drive the real vulnerability flow (appendVulnerabilityPackageRules) through the
real lookupUpdates, instead of only simulating the generated packageRule. Also
reword the inline comment and use luxon/asTimestamp for timestamps.
* test: fix type-check on e2e lookup config
Cast the spread config to satisfy partial() overload resolution, matching the
existing `getConfig() as never` idiom in the lookup spec.
* test: drop redundant inline lookup test in favor of end-to-end coverage
The simulated lookup test hand-built the security packageRule; the end-to-end
test plus the generated-rule assertion in vulnerabilities.spec.ts cover the same
behavior against the real flow, so the inline test added no unique coverage.
* test(vulnerability): align lookup config types
Previously, if we ticked the checkbox for a PR that's open, but has
pending updates, we recreate the branch with the latest version,
regardless of whether it's `pending` or not.
This can lead to cases where we accidentally bring an update that's not
passed `minimumReleaseAge` into the branch.
To prevent this, we can make sure that we only treat a Dependency
Dashboard checkbox/PR rebase request as consent for an update when it is
the new `unpend` check, or when using `checkedBranches`.
For visibility, we both log an INFO and `ensureComment` on the PR to
indicate why this branch isn't being updated past the version we're
currently proposing (which may change from the rebase update, but won't
include a pending version).
The comment is removed once a requested rebase is applied, and is only
removed when rebases are requested, avoiding unnecessary platform
requests on non-rebase updates.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
As part of follow-up changes, we're looking to correct behaviour when
rebasing a given open PR, where the PR includes a set of pending
changes.
Before we do this, we can refactor the dependency dashboard to add a new
`unpend` check type, to say "create a branch, even though I know the
branch is pending status checks".
Previously, this section would share `approvePr` alongside other checks,
which may not make sense.
As `approvePr` currently forces PR creation, we need to treat `unpend`
similarly, so we don't create the branch, but not the PR when i.e.
`prCreation=approval`.
As the Dashboard is being re-rendered, a checkbox that was previously
checked (before this version of Renovate) will need re-checking.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
As part of future changes, we're adding a new type of checkbox for the
Dependency Dashboard.
Before we do this, we can extract an enum for the known types.
We don't touch `dependencyDashboardChecks` itself, as that also includes
`configMigrationCheckboxState`, which isn't related to the per-branch
checks.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
* fix: preserve current compatibility after lookup
* fix: expose current compatibility in lookup result
* test: preserve current compatibility after lookup
* test: preserve compatibility through fetch
* test: isolate current compatibility regression
* test: isolate current compatibility regression
* test: isolate current compatibility regression
* test: isolate current compatibility regression
* fix(manager): handle registryAliases with shell variable defaults
Allows `registryAliases` keys to contain shell-style variables with
empty (or other) defaults, e.g. `${DEPENDENCY_PROXY:-}` or
`${CI_REGISTRY:-}`. The same image string is then resolved both
online (variable expanded) and offline (variable empty).
Changes in `dockerfile/extract.ts` (used by `gitlabci` too):
* Match the alias key as either `${name}/...` (existing) or `${name}...`
when `name` already ends in a non-identifier boundary character such
as `}`. Bare-identifier keys like `$CI_REGISTRY` continue to require
the slash boundary so they no longer overmatch keys that begin with
the same prefix (e.g. `$CI_REGISTRY` vs `$CI_REGISTRY_IMAGE`).
* Use `ensureTrailingSlash` to handle alias values that already include
a trailing slash.
* Preserve the original `name` and path structure in `dep.depName`
instead of substringing only after the alias `value`. This keeps the
variable in the depName so it survives a `splitImageParts` round-trip
and the resulting branch name comes out clean.
Adds `sanitizeDepName` regex passes in
`lib/workers/repository/updates/flatten.ts` so any leftover
`${VAR}`/`${VAR:-...}` placeholder is stripped from the depName before
it becomes a branch name (otherwise we'd get
`renovate/${dependency_proxy}python-3.x` instead of
`renovate/python-3.x`).
Tests cover:
* `${VAR:-}/image` (with slash) and `${VAR:-}image` (no slash, requires
the boundary form).
* Overlapping prefixes: `$CI_REGISTRY` vs `$CI_REGISTRY_IMAGE`.
* Registry alias with port (`localhost:5000/repo`).
* `sanitizeDepName` strips `${VAR}` / `${VAR:-}` / bare `$VAR`.
Reproducer: https://github.com/Wayneoween/renovate-36293-repro
* revert(manager/gitlabci): keep regex group name as 'prefix'
Reverting the unrelated `prefix` -> `rawPrefix` rename in `depProxyRe`.
Per review on #36293, this rename is out of scope for the registry-alias
fix and just adds review surface.
* refactor(manager/dockerfile): narrow alias boundary check to '}'
Per review on #36293. The previous regex `/[^A-Za-z0-9_]$/` matched any
non-word ending, which is broader than the documented case (alias keys
ending in `}` from `${VAR}` / `${VAR:-...}`). Replace with a plain
`name.endsWith('}')` check, which also avoids re-building a regex on
every iteration of the alias loop.
Existing tests (`'variables with default and slash'`,
`'variables with default no slash'`, `'alias with digest only'`)
continue to exercise the `}`-boundary path; the `'overlapping prefixes'`
case continues to exercise the slash-only path.
* chore(manager/dockerfile): trim comment and TODO library/ strip edge
Per review on #36293:
* Drop the verbose explanation block above the depName-restore branch;
the spec rows already document the expected shape.
* Add a TODO above the `dep.depName?.startsWith(valueWithSlash)` guard
noting a pre-existing edge case: when the inner `getDep` strips a
`library/` prefix (or similar) the depName no longer starts with
`valueWithSlash`, so the alias-rooted depName is not restored. Out of
scope for this PR.
* fix(manager/dockerfile): handle empty registry alias value
- strip trailing slash after ${VAR} placeholders in sanitizeDepName
- treat an empty registry alias value as Docker Hub instead of '/'
- clarify registry alias docs wording
* refactor(manager/dockerfile): drop redundant alias boundary guard
- `matchedAtBoundary` is only read behind `!matchedWithSlash`
- add docker-compose test for `${VAR:-}` registry aliases
* test(manager/dockerfile): pin special-prefix registry alias behavior
`getDep` strips `library/`, `amd64/` and `arm64/` as special prefixes, so
an alias whose value is one of those loses its alias-rooted `depName`.
Both the slash form and the variable form behave this way on `main`.
* refactor(lint): enable oxlint prefer-named-capture-group at error
Numbered capture groups (m[1], $1) break silently when a regex is
edited and group order shifts. Named groups (?<name>...) make intent
explicit and accesses (m.groups.name) resilient to reordering.
This enables the built-in eslint rule prefer-named-capture-group,
surfacing 321 pre-existing unnamed-group violations across ~121
files to be burned down incrementally in follow-up commits.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RxHFNsSworLcv23xXk9Hk
* refactor(versioning): name capture groups for prefer-named-capture-group
Burns down all prefer-named-capture-group violations in
lib/modules/versioning/. Unused capture groups (only reachable via
.test() or whole-match) become non-capturing (?:...); groups whose
value is read become named (?<name>...), with accesses rewritten to
match.groups!.<name> (or destructured from .groups!) instead of
positional match[n]/$n so a future edit that reorders groups cannot
silently break the reader.
Two cases needed extra care to preserve behavior:
- semver/common.ts and poetry/patterns.ts split() on a regex whose
capture group is relied upon by String.prototype.split to keep the
separator in the output array; the group is kept capturing and
named, not converted to non-capturing.
- hashicorp/convertor.ts's semverRegex is only ever embedded via
.source into a named `(?<version>...)` group elsewhere and never
matched directly, so its internal groups are safe to make
non-capturing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RxHFNsSworLcv23xXk9Hk
* refactor(datasource): name capture groups for prefer-named-capture-group
Burns down all prefer-named-capture-group violations under
lib/modules/datasource/. Same treatment as the versioning module:
unused groups become non-capturing, used groups get names, and
positional match[n] reads move to match.groups!.<name>.
docker/ecr.ts and pypi/common.ts keep their positional destructuring
(`const [, region] = ...`, `!!m &&`) working unchanged since a named
capture group is still addressable by its numeric index in
JavaScript — only pypi/common.ts's access was rewritten to
m.groups!.owner for clarity since it read a single group directly.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RxHFNsSworLcv23xXk9Hk
* refactor(platform): name capture groups for prefer-named-capture-group
Burns down all prefer-named-capture-group violations under
lib/modules/platform/. Uses the repo's established idiom of
`match.groups?.<name>` after an optional-chained exec()/match() (see
bitbucket/index.ts hostnameWithoutApiPrefix, gerrit/utils.ts
extractSourceBranch) and `$<name>` in String.replace replacement
strings. Unused groups (markdown/HTML massaging regexes matched only
to be stripped) become non-capturing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RxHFNsSworLcv23xXk9Hk
* refactor(manager): name capture groups in ansible-galaxy for prefer-named-capture-group
Burns down prefer-named-capture-group violations in
lib/modules/manager/ansible-galaxy/. newBlockRegEx and blockLineRegEx
dropped their unused outer wrapping group (only the inner key/value
groups were ever read) and named the key/value groups; nameMatchRegex's
remaining unused groups (protocol/user-info/port alternatives) become
non-capturing since only source/hostname/depName/version are read via
.groups. Accesses in collections.ts and roles.ts move from
lineMatch[2]/lineMatch[3] to lineMatch.groups!.key/value.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RxHFNsSworLcv23xXk9Hk
* refactor(manager): name capture groups for prefer-named-capture-group (batch 1)
Burns down prefer-named-capture-group violations across the first
alphabetical slice of lib/modules/manager/ (ansible through mix).
Used groups get names with accesses rewritten to match.groups!.<name>
(or $<name> in replacement strings); groups whose value is never read
become non-capturing (?:...). Two String.split() call sites
(git-submodules/extract.ts, meteor/extract.ts) keep the established
"named group still readable positionally from the split() result
array" idiom instead of restructuring the destructuring.
bazel/rules/go.ts and buildpacks/extract.ts dockerRef verified
byte-for-byte equivalent before/after via a quick node script since
several nested groups collapsed to non-capturing at once.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RxHFNsSworLcv23xXk9Hk
* refactor(manager): name capture groups for prefer-named-capture-group (batch 2)
Burns down prefer-named-capture-group violations across the remaining
alphabetical slice of lib/modules/manager/ (npm through terragrunt).
Same treatment as batch 1: used groups get names with accesses moved
to match.groups!.<name> or $<name> replacement strings; unused groups
(wrapping alternations, quantifier repetition groups only consumed via
.test(), or values never read from a match) become non-capturing.
terraform/extractors/others/modules.ts and terragrunt/modules.ts share
near-identical URL-parsing regexes (github/bitbucket/git/azure-devops
ref matchers) — the same set of always-unused `depth=`/`&depth=`
query-string groups is converted to non-capturing in both files.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RxHFNsSworLcv23xXk9Hk
* refactor(config): name capture groups for prefer-named-capture-group
Burns down prefer-named-capture-group violations in lib/config/.
Used groups get names with replacement strings switched from $1/$2 to
$<name>; the unused separator group in schedule-migration.ts's
afterBeforeRegex becomes non-capturing. presets/parse.ts keeps
assigning through the already-declared `repo` variable rather than
array-destructuring the exec() result, matching this file's existing
style for the other named-group regexes just above it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RxHFNsSworLcv23xXk9Hk
* refactor(util): name capture groups for prefer-named-capture-group
Burns down prefer-named-capture-group violations across lib/util/ and
lib/logger/. Same treatment as previous batches: named groups for
values that are read (via $<name> replacement strings, .groups!.<name>,
or destructured from .groups), non-capturing groups where nothing reads
the captured value (e.g. semantic.ts's angular-commit .test()-only
regex). www-authenticate.ts's tokenizer entries each get their own
named group but keep accessing the match generically via match[1],
since a positionally-indexed named group is still readable by index.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RxHFNsSworLcv23xXk9Hk
* refactor(workers): name capture groups for prefer-named-capture-group
Burns down prefer-named-capture-group violations in lib/workers/.
Used groups get names with $<name> replacement strings; unused
wrapper/alternation groups (e.g. semantic-commit-message.ts's optional
scope/issue wrappers, release-notes.ts's date-heading and
horizontal-rule matchers that are only probed with .search()/replaced
wholesale) become non-capturing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RxHFNsSworLcv23xXk9Hk
* refactor(test,tools): name capture groups for prefer-named-capture-group
Finishes the prefer-named-capture-group burndown: test/, tools/, and
vitest.config.mts. Groups whose value is read get names ($<name>
replacement strings or .groups.<name> access); groups only used via
.test()/.search() or that feed a .match(/…/g) call (whose return value
is the array of whole matches, not captured groups) become
non-capturing.
This is the last remaining slice of pre-existing violations, so the
rule (already enabled at error repo-wide) now passes with zero
findings across the whole codebase.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RxHFNsSworLcv23xXk9Hk
* fix prettier failure
* refactor(lint): use a named capture group in `v8-ignore-no-count`
New rule from main trips the newly enabled `prefer-named-capture-group` oxlint rule.
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
As part of changes we've recently made to the merging of
`hostRules[].headers`, it highlighted that a repository - or a preset
it extends - could lead to a header an admin has configured for one host
to be sent to another.
This happened due to the way we additively merged i.e.
`Object.assign({}, ...matchedHeaders)`.
This doesn't require the repository to know a credential is being
set (for a specific host), or to act maliciously - any header of their
own for that host is enough to bring the administrator's masked one
back, with nothing logged or failing to show it happened.
To fix this, we can:
- apply admin headers last, as they are "trusted"
- stop repositories from being able to unset an admin-set header
- retain the existing logic for the "most specific rule" being used
- make sure that `trusted` isn't a field that could be injected by a
repository, and make sure we explicitly only set it where we know
we're using self-hosted administrator config
- make `filterAllowedHeaders` drop `headers` if every header name was
denied, so `{}` isn't returned and used to suppress headers when
merged
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
We previously enforced `allowedHeaders` by making sure that each
`hostRules.add()` call had `filterAllowedHeaders`.
This isn't super future proofed, and although we could add a linting
rule, we should instead enforce this by making sure that
`hostRules.add()` applies the filtering.
This also catches cases like host rules from `.npmrc` which wasn't
currently being filtered - albeit there was no means to bypass
`allowedHeaders`.
Moving `filterAllowedHeaders` into `lib/util` removes a dependency from
the global bootstrap and `config-validator` importing from
`lib/workers/repository/init/`.
While doing so, we can also make sure that:
- we log only one WARN for global `hostRules` being invalid, rather than
once per `repositories[]`
- `renovate-config-validator` validates a global config file's
`hostRules` against that file's own `allowedHeaders`, like a real run
would after parsing it
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
Previously, if there was a `hostRule[].headers` value for a given host
set in both global self-hosted configuration and repo config, the repo
config would overwrite /all/ headers set by the admin.
To resolve this, we can now correctly merge the keys, with the repo
config taking priority.
This still only takes into account the `allowedHeaders`, so a repository
cannot bypass admin settings.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
For some time, admin configuration for `hostRules[].headers` was
enforced through `allowedHeaders`, but no validation feedback was given
to administrators, as it was silently ignored when `applyHostRule` runs.
To provide visibility to administrators who were setting headers that
were silently being ignored, we can instead provide validation at the
time we set our global host rules.
In a future change, we'll align the behaviour of `allowedHeaders` and
`allowedEnv` to make it so admin-controlled `hostRules` aren't bound by
the `allowedHeaders` flag.
We can also make it clear in the documentation that this is the
behaviour.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
As a further level of defence-in-depth for fixes on top of `allowedEnv`
and `allowedHeaders` enforcement, we can also make sure that we're
performing full config validation for the resolved configuration.
This allows us to report any configuration errors/warnings when we
include the full resolved configuration, without necessarily blocking
the full Renovate run, unless using `configValidationError`.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
This change was broken out of another commit, but it is unclear which AI
model was used to make the change, so we need to note both.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
As an additional defence-in-depth, we can make sure that when applying
the `headers` configuration (from repo config, or presets) we
re-validate it.
We allow any admin-supplied configuration regardless, and then any
user-supplied settings are re-filtered according to `allowedHeaders`.
Due to the existing way that header merging incorrectly merges the repo
(or preset) `headers` over the admin config, we don't currently handle
this explicitly, unlike `filterAllowedEnv`.
If a user-supplied setting is filtered, we log a WARN message to inform
the user - and the admin - that this is ignored.
At this point, we don't try and explain which preset(s) this may have
come from, only that there is an issue.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
As an additional defence-in-depth, we can make sure that when applying
the `env` configuration (from repo config, or presets) we re-validate
it.
We allow any admin-supplied configuration regardless, and then any
user-supplied settings are re-filtered according to `allowedEnv`.
If a user-supplied setting is filtered, we log a WARN message to inform
the user - and the admin - that this is ignored.
At this point, we don't try and explain which preset(s) this may have
come from, only that there is an issue.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
As part of follow-up changes, we'll be better enforcing the
`allowedHeaders` validation.
Before we do this, we should make sure that we have relevant test cases
to cover the existing (broken) behaviour.
We should cover this across both Config Validation and how config is merged.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
As part of follow-up changes, we'll be better enforcing the `allowedEnv`
validation.
Before we do this, we should make sure that we have relevant test cases
to cover the existing (broken) behaviour.
We should cover this across both Config Validation and how config is merged.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
A registry host never appears in a Git tag, so a host-qualified name
such as an OCI chart `<registry>/<org>/<repo>/<chart>` can never match
the tag that publishes it, which is scoped by the chart name alone:
`<chart>-<version>`. Match those names against their host-stripped form
and against their trailing path segment as well. Names that are not
host-qualified, such as scoped npm packages, keep matching in full only.
Escape the interpolated names and version too, so a `.` in a registry
host no longer acts as a wildcard and a name containing regex
metacharacters cannot throw out of `regEx()`.
Signed-off-by: Dennis Witt <dennis@derwitt.de>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* fix: honour dashboard rebase for edited branch with no open PR
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* test: drop unconsumed findPr mocks from dashboard rebase test
The new guard short-circuits before platform.findPr, so the mocks were
never reached and the two tests were identical; collapse into one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test: assert commitSha loosely in dashboard rebase test
main replaced the shared `'123test'` mock value with `fakeSha('123test')`,
so the literal no longer matches on the merge ref.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Gregor Zeitlinger