* test(manager): replace file snapshots with explicit assertions
* test(manager): replace inline snapshots with explicit assertions
* test(manager): assert on relevant sections instead of full bodies
* test(manager): drop assertions implied by full equality
* test(manager): address review feedback
* test(manager): assert depType and versioning in the regex matcher
* refactor(github): model GitHub hosts explicitly
* refactor(github): move `isGithubEnterpriseServer()` to utils
* test(github): cover version-gated features with unknown GHES version
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/npm): massage out lockstep siblings pinning the replaced version
When updating an npm dependency, the package-lock massage deletes only
node_modules/<depName> before running npm install. Lockstep monorepo
siblings (e.g. vue -> @vue/server-renderer) that exact-pin the updated
dependency stay in the lock at the old version. npm then places the
fresh dependency into the hole, keeps the stale sibling (it still
satisfies its own demanding edges), and hard-fails with ERESOLVE on the
sibling's exact peer pin.
Also massage out lock entries whose dependencies/peerDependencies pin
the updated dependency to exactly the version being replaced, so npm
re-resolves the whole family in lockstep. The version guard keeps the
deletion precise: range pins and unrelated exact pins are untouched.
See discussion 44664.
* fix(manager/npm): address review feedback
- drop unreachable packages guard, wrap deletion loop instead
- flatten sibling check with early continue
- match exact pins per field, including optionalDependencies
- inline lockfile fixture, cover all three pin paths
* 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`.
* fix(gerrit): resolve relative submodule URLs for nested project paths
* Fix tests after rebase
---------
Co-authored-by: Felipe Santos <felipe.santos@ericsson.com>
* 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>
* feat(lint): add renovate/prefer-is-helpers and renovate/prefer-is-object rules
Flag ad-hoc type checks that have @sindresorhus/is equivalents:
- .filter(Boolean) -> .filter(isTruthy)
- typeof x === 'string' -> isString(x)
- x === null || x === undefined -> isNullOrUndefined(x) (and negation)
The typeof x === 'object' shape lives in a separate suggestion-only rule
(renovate/prefer-is-object, kept at warn) because isObject()/isPlainObject()
are not drop-in equivalents: null, arrays and functions behave differently.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: fix renovate/prefer-is-helpers violations
Replace ad-hoc type checks with @sindresorhus/is helpers across lib/:
- 13x .filter(Boolean) -> .filter(isTruthy)
- 36x typeof x ==/!== 'string' -> isString(x) / !isString(x)
- 6x x === null || x === undefined -> isNullOrUndefined(x) (and negation)
Promote renovate/prefer-is-helpers to error now that the codebase is clean.
renovate/prefer-is-object stays at warn: its 15 remaining sites guard
parsed YAML/JSON or unknown values where isObject()/isPlainObject() are
not provably equivalent (null/array/function semantics).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: enforce renovate/prefer-is-object at error level
Resolve the 15 remaining warnings and raise the rule from warn to error:
- Migrate 10 sites to isObject() where the guarded value provably cannot
be a function (parsed YAML/JSON, typed exec command arguments, or
test-controlled fixtures): helm-values, woodpecker, bun, pre-commit
managers, exec utils, file package cache, and the github http spec.
In the bun manager this also fixes a latent crash where a null
`workspaces` value would throw on the `in` operator.
- Keep 5 sites as reasoned oxlint-disable comments where excluding
functions is load-bearing: the byte-exact fingerprint canonicalizer
(2), the circularity walker, the zod result guard, and the generic
hasKey helper.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* feat(lint): add renovate/inline-single-use-fixtures rule
In spec files, a module-scope const fixture that is referenced from
exactly one it()/test() block should be inlined into that test so the
test is self-contained. The rule is a warn-level nudge (naming for
clarity is a valid exception) with no autofix (moving code is risky).
Uses oxlint jsPlugins scope analysis (getDeclaredVariables) for exact,
shadowing-safe reference counting and bails out conservatively: only
top-level non-exported single-declarator consts with multiline,
non-function initializers whose every reference sits inside the callback
function of one and the same test call are flagged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: inline single-use spec fixtures into their tests
Fix 26 renovate/inline-single-use-fixtures warnings in specs where the
move is mechanical and value-preserving: codeBlock fixtures were
re-indented uniformly (codeBlock strips the common indentation, so the
produced string is unchanged) and Fixtures.get() calls resolve relative
to the spec file, so relocating them inside the test body has no effect.
The remaining 59 warnings are left for per-site judgment, as the rule is
a warn-level nudge by design.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: inline remaining relocation-safe single-use spec fixtures
Move the 24 remaining single-use module-scope fixtures whose initializer
is a codeBlock tagged template or a Fixtures accessor call into the one
it() block that uses them. Both shapes are value-preserving to relocate:
codeBlock strips the common leading indentation, so the uniformly
re-indented templates produce identical strings, and Fixtures.get()
resolves relative to the spec file, not the call site's position in it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* feat(lint): enforce inline-single-use-fixtures as error
Narrow the rule to the initializer shapes where moving the declaration
into the test body is provably value-preserving and unambiguously an
improvement: codeBlock/stripIndent tagged templates (indentation-
normalizing, so re-indenting is safe) and Fixtures accessor calls
(resolve relative to the spec file). Plain object/array literals,
untagged template literals (whose leading-newline formatting would need
ugly re-indentation) and arbitrary call expressions remain per-site
judgment calls and are no longer flagged.
With the rule reduced to true defects and all remaining violations
inlined, bump it from warn to error in the spec override block.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: inline contents of fixtures relocated into single-use tests
The previous commits moved single-use module-scope Fixtures.get() consts
into their one it() block, which only relocated the file indirection.
Replace those relocated Fixtures.get() calls with the fixture file's
actual content — codeBlock tagged templates for text fixtures — so the
tests are self-contained, and delete the fixture files that no longer
have any references. Relocated fixtures too large to inline comfortably
(terraform-provider releases, sbt private-variable file, nuget v2 pkg
list, bundled package-lock) keep their Fixtures.get() calls.
Value preservation was verified by unchanged vitest results for every
touched spec; all consumers parse the content, so codeBlock's trailing
newline normalization is behavior-neutral.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: inline remaining large single-use fixtures
Inline the four Fixtures.get() sites that were previously exempted for
size, so every single-use fixture is now inlined regardless of size:
- nuget v2_withoutProjectUrl.xml -> codeBlock (served via http mock)
- terraform-provider releaseBackendIndexGoogleBeta.json -> plain object
literal passed to the nock reply
- npm locked-dependency bundled.package-lock.json -> codeBlock JSON
string (consumed as raw lockFileContent)
- sbt private-variable-dependency-file.scala -> codeBlock
All consumers parse the content, so codeBlock's trailing-newline
normalization is behavior-neutral; vitest results are unchanged for
every touched spec, including the two pre-existing nuget failures.
The nuget, terraform-provider and sbt fixture files have no remaining
references and are deleted. bundled.package-lock.json is kept because
package-lock/get-locked.spec.ts still reads it via Fixtures.getJson().
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: keep large bundled package-lock fixture in a file
The bundled package-lock.json inlined into the "fails remediation if
bundled" test is ~150 KB (~4,400 lines); inlining it as a codeBlock
hurts readability more than it helps. Read it via Fixtures.get inside
the test block instead — the inline-single-use-fixtures rule permits a
Fixtures.get() call in test scope, and the fixture file is still present.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
perf(package-rules): avoid re-cloning packageRules array on every rule merge
applyPackageRules() merges each matching rule via mergeChildConfig(),
which deep-clones the entire accumulated config — including the
invariant packageRules array itself. On repos with many dependency
instances and large rule arrays (e.g. vulnerabilityAlerts force-rules
embedding advisory texts), this cloning dominates the whole run
(observed at ~66% of total CPU in a production profile).
Exclude packageRules from the working config while rules are applied
and restore it afterwards, preserving the previous merge semantics for
rules that themselves carry nested packageRules, and for null/empty/
absent inputs.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* refactor(datasource/orb): use REST API instead of graphql-unstable
Switch the orb datasource from the `graphql-unstable` GraphQL endpoint to
the stable CircleCI REST API (`GET /api/v3/orb/packages?filter[name]=`).
The single REST call returns the same fields the datasource needs
(`is_private`, `home_url`, and the nested `orb_versions` with
`created_at`), so behaviour is unchanged for public and private orbs on
circleci.com. Missing orbs are now detected via an empty `data` array
rather than a null `orb` field.
* convert to zod schema
* refactor(datasource/orb): use nullish helper and schema-side transform
Address review feedback:
- use the Nullish schema helper for optional attributes
- catch([]) so orb_versions is never null/undefined
- move the data transform (isPrivate, releases) into the schema; the
homepage fallback stays in the datasource since it needs the requested
packageName
* refactor(datasource/orb): drop snapshot and use toEqual assertion
* refactor(datasource/orb): change assertion to deepnullish
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
---------
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.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 they shouldn't be allowed, and we should therefore - loudly - block
them.
This migrates them to being a "security" error, given it's a config
option that is blocked for security reasons.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
As they shouldn't be allowed, and we should therefore - loudly - block
them.
This migrates them to being a "security" error, given it's a config
option that is blocked for security reasons.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
As a means to catch options setting `requiresCheckAtTrustBoundary`, we can add a test that is more of a reminder
than an enforcement.
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 noticed while working on this branch, we currently do not merge an
admin's `hostRules` settings, if a user has (in repo or preset config)
specified `hostRules` themselves, when targeting the same `matchHost`.
To cover the existing (broken) functionality, we can document this with
a test.
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>
As part of follow-up changes, we'll introduce stricter validation for
config options that need to be re-validated before use.
We can prefactor by adding a new field to the config options, and making
sure it doesn't appear in the generated docs.
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>
We've previously been incorrectly caching the error responses from the
Go proxy occurs, which leads to a lot of "flapping" of PRs on
Mend-hosted apps, and can be rather frustrating as a user (and a service
owner).
Per the Go proxy protocol[0], a `,` fallback strategy should only
continue to the next entry on 404/410, and otherwise propagate the
error.
However, we currently break out of the loop and return `result` (which
may be `null` if no successful requests have been performed yet).
This `null` would be cached, leading to a "no releases found"
(`no-result`), stored in the "hard TTL" cache, which could lead to many
days without an update for given packages.
To fix this, we can make sure that we propagate errors, which would
mean that on an error:
- if we've previously successfully retrieved the package, serve the
"last good" result
- if we haven't, it's a full error, and the datasource can retry
[0]: https://go.dev/ref/mod#goproxy-protocol
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As part of follow-up changes, we'll fix a bug with how the caching of
error responses from the Go proxy occurs, which leads to a lot of
"flapping" of PRs on Mend-hosted apps, and can be rather frustrating as
a user (and a service owner).
Per the Go proxy protocol[0], a `,` fallback strategy should only
continue to the next entry on 404/410, and otherwise propagate the
error.
However, we currently break out of the loop and return `result` (which
may be `null` if no successful requests have been performed yet).
Before we fix our behaviour, we need to clarify what our current
behaviour is.
[0]: https://go.dev/ref/mod#goproxy-protocol
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
Lock file maintenance deletes package-lock.json and regenerates it from
scratch, and a single npm install pass can produce a lock file that is out
of sync with package.json, so npm ci rejects the branch. Always run the
install command a second time for lock file maintenance, mirroring the
existing double run for remediations, instead of relying on users opting
in to the npmInstallTwice postUpdateOption. Because branch creation and
rebase share the same lock file generation path, this covers both.
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>
* feat(manager): add apm manager for Agent Package Manager
Add a new `apm` manager that updates git-pinned dependencies in APM
(Agent Package Manager) `apm.yml` manifests, as requested in
renovatebot/renovate#42507.
The manager parses the string entries under `dependencies.apm` and
`devDependencies.apm` (`[host/]owner/repo[/subpath]#<ref>`) and selects
the datasource dynamically from the git host, reusing the existing
github-tags, gitlab-tags and git-tags datasources. MCP entries carry no
pinnable version and are ignored.
When an `apm.lock.yaml` lockfile is present, it is refreshed by running
`apm install` via a new `apm` tool constraint (pypi `apm-cli`).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vfjt3BpqDriiVsvwqVe9M9
* fix(manager/apm): resolve apm tool from github releases
APM ships self-contained binaries as GitHub release assets
(apm-linux-<arch>.tar.gz under vX.Y.Z tags), not as the PyPI apm-cli
wheel. Point the apm tool constraint at the github-releases datasource so
the version Renovate resolves matches the artifact that actually gets
installed, stripping the leading `v` from the tag.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vfjt3BpqDriiVsvwqVe9M9
* docs(manager/apm): point to canonical microsoft/apm repository
The APM project's canonical home is github.com/microsoft/apm (originally
danielmeppiel/apm). Update the manager URL and readme accordingly.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vfjt3BpqDriiVsvwqVe9M9
* refactor(manager/apm): validate manifest with zod schema
Address review feedback on the apm manager:
- parse `apm.yml` with a dedicated zod schema via
`parseSingleYaml(content, { customSchema })` instead of casting the
parsed YAML to `ApmManifest`
- `LooseArray(z.string())` keeps only the string dependency entries, so
MCP objects and other non-string values are dropped by the schema and
the manual `Array.isArray`/`is.string` guards are no longer needed
- drop the `as SkipReason` casts now that the literals are inferred
- remove the now-unused `types.ts`
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UbMAQBiMRNkCNxc8EGQw1C
* Update schema.ts
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* Update readme.md
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* Update readme.md
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* refactor(manager/apm): simplify manifest schema and host detection
Address review feedback:
- default the `apm` array to `[]` in the schema (`LooseArray(...).catch([])`)
since LooseArray already discards non-string entries, so downstream code
no longer needs to handle `undefined`
- use `coerceArray` when mapping the optional dependency sections
- drop the redundant `host === 'github.com'` / `host === 'gitlab.com'`
checks in datasource selection; `detectPlatform` already resolves those
hosts (the explicit host comparison is only kept to decide registryUrls
for self-hosted instances)
- document that APM only supports remote git references and that dots in
repo names / subpaths are handled, with a regression test
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UbMAQBiMRNkCNxc8EGQw1C
* docs(manager/apm): fix readme trailing newline
Remove the trailing blank line left after the readme edits so it passes
`prettier` and `markdown-lint`.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UbMAQBiMRNkCNxc8EGQw1C
* refactor(manager/apm): parse dependency path with named capture groups
Replace the manual host/owner/repo splitting (and the standalone dot
regex) with a single named-capture regex, as suggested in review. `owner`
excludes dots so the optional hostname segment is unambiguous, while repo
names and subpaths may still contain dots.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UbMAQBiMRNkCNxc8EGQw1C
* test(manager/apm): align admin config with InternalGlobalConfigOptions
`localDir` moved out of `RepoGlobalConfig` into `InternalGlobalConfigOptions`
on main, so annotate the test admin config as
`RepoGlobalConfig & InternalGlobalConfigOptions`, matching the other
manager artifacts specs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UbMAQBiMRNkCNxc8EGQw1C
* fix(manager/apm): resolve GitLab nested groups and recognize SHA-pinned refs
- resolve nested GitLab project slugs (e.g. `group/subgroup/project`)
instead of capping at `owner/repo`, splitting the project from any
virtual-package subpath using APM's primitive-dir / virtual-file markers
- recognize the documented SHA-pinned form and skip it
(`unversioned-reference`) rather than treating the SHA as a version or
rewriting it
* feat(manager/apm): support digest pinning for SHA-pinned deps
Recover the release tag from the trailing YAML comment of a SHA-pinned
entry (`owner/repo#<sha> # v2.0.0`) - which the structured parse strips -
so it extracts as a digest (`currentDigest` + `currentValue`) and updates
both via `pinDigests`, mirroring the github-actions manager. A bare SHA
with no tag comment (or a quoted form we can't rewrite verbatim) is left
skipped.
* fix(manager/apm): map SHA-pin tag recovery per line to handle duplicates
The raw-manifest scan matched the first line for the entry regardless of
section, so the same `owner/repo#<sha>` pinned in both `dependencies` and
`devDependencies` resolved to the first line's tag/replaceString. Consume
each line at most once (in file order) so duplicate pins map to distinct
lines.
* fix(manager/apm): recognize `.chatmode.md` virtual files
APM's VIRTUAL_FILE_EXTENSIONS includes `.chatmode.md`; add it to the
subpath-boundary regex so a `*.chatmode.md` virtual dependency on a
nested-group host (GitLab, Azure DevOps) is not folded into the repo path.
* test(manager/apm): cover SHA-pin digest updates on git-tags hosts
Lock in that a SHA-pinned dep on a non-github/gitlab host resolves via the
git-tags datasource (which supports `getDigest` through `git ls-remote`),
so the commit is preserved on a bump rather than dropped.
* fix(manager/apm): commit regenerated harness files, not just the lockfile
`apm install` re-deploys the harness directories APM consumers commit
(`.github/`, `.claude/`, ...), but updateArtifacts only returned
`apm.lock.yaml`, leaving instruction files stale after a bump. Capture
every file the install changed via `getRepoStatus` (additions +
deletions); the gitignored `apm_modules/` cache is excluded, and the
manifest stays with `updatedPackageFiles`.
* fix(manager/apm): declare lockFileMaintenanceIsDelegatedToPackageManager
main now requires managers with `supportsLockFileMaintenance` to set this
field. apm regenerates the lockfile via `apm install`, so it delegates to
the package manager (`true`).
* refactor(manager/apm): reuse shared regex and git-sha helpers
Adopt the shared utilities per review:
- use the exported `newlineRegex` from `util/regex` instead of a local copy
- use `isLongCommitSha` from `util/schema-utils/git` instead of a bespoke
SHA regex
- filter path segments with `isTruthy` instead of `Boolean`
* test(manager/apm): align docker exec snapshot with current base-image wrapper
The shared `util/exec` docker wrapper now injects `-e CI` and single-quotes
the `bash -l -c` payload. Update the docker-mode expectation to match, so the
snapshot tracks the current wrapper output.
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* fix(bitbucket): use effective-branching-mode endpoint for bbUseDevelopmentBranch
Signed-off-by: Fernando Fernández <ferferga@hotmail.com>
* refactor(bitbucket): add more logging around BitBucket's branching model
Signed-off-by: Fernando Fernández <ferferga@hotmail.com>
* test(bitbucket): update mock for effective-branching-model
Signed-off-by: Fernando Fernández <ferferga@hotmail.com>
* test(bitbucket): fix forgotten test mock
Signed-off-by: Fernando Fernández <ferferga@hotmail.com>
* chore: address review comments
Signed-off-by: Fernando Fernández <ferferga@hotmail.com>
* fix(bitbucket): tests and types
Signed-off-by: Fernando Fernández <ferferga@hotmail.com>
---------
Signed-off-by: Fernando Fernández <ferferga@hotmail.com>
Sebastian Poxhofer