updateLockedDependency() only searched the packages section of
composer.lock, so updates to packages-dev dependencies were never
recognized as already committed to the branch. Every Renovate run then
fell back to a full artifact update and rebuilt the branch from a clean
base, force-pushing grouped composer PRs containing dev dependencies
whenever the base branch had moved - even with identical content.
In some cases, we hadn't correctly wired in the `minimumReleaseAge`
checks for `digest`, due to the `currentValue` not changing.
To handle this, we need to:
- use our helper methods for calculating whether the `minimumReleaseAge`
has passed
- handle a new digest's new `releaseTimestamp`
the current timestamp
- intentionally not gate `minimumConfidence`, as this is only computed
per-release, not at the digest level
- note the fixed behaviour, and clarify when it will/will not work
- add coverage for all generated updates for `digest`s, including when
remapping a Go Modules update as a `digest`
- clarify that `filterInternalChecks` and
`applyMinimumReleaseAgeToDigestUpdate` should stay in sync
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
* chore(config): be explicit about `Renovate CLI` in `prFooter`
This was something I should have done in
72968d3726.
* fixup! chore(config): be explicit about `Renovate CLI` in `prFooter`
* fix(config-validator): warn when RE2 is not in use
Without RE2 the validator checks patterns with the JS RegExp engine, which
accepts syntax RE2 rejects, so configs can validate clean here and then be
rejected when Renovate runs.
Co-Authored-By: Claude (Opus 5) <noreply@anthropic.com>
* fix(config-validator): debug log for the RE2 opt-out
Setting RENOVATE_X_IGNORE_RE2 is deliberate, so it does not warrant a warning,
matching what the global worker already does.
Co-Authored-By: Claude (Opus 5) <noreply@anthropic.com>
---------
Co-authored-by: Claude (Opus 5) <noreply@anthropic.com>
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
* docs(next-major): update links to Renovate 44 examples
After the inadvertent release of Renovate 44, we still need to follow
post-release actions, so we may as well keep these updated.
* docs(next-major): add reference to major version bump in docs
Renovate 44.0.0 was incorrectly released from #44004 due to the
`BREAKING ...` reference in the commit message.
Renovate uses Squash Merge as our method for merging commits into
`main`, and when enabled with the Merge Queue[0], this doesn't provide
maintainers with the ability to inspect the commit messages before
merging (which would be the case if not using the Merge Queue, we would
likely rewrite the commit message prior to merge.
With this in mind, Renovate maintainers often don't inspect the commit
messages, allowing them to stay as they are, as they'll be squashed into
the final commit.
In the case of #44004, this led to us missing the `BREAKING ...`
trailing message - from changes that were split into #44939 - and
because of this, semantic-release published this as a major release.
As a means to prevent this happening again, we can introduce a CI check
that performs a full `semantic-release --dry-run` programatically, so we
can avoid relying on log lines from `semantic-release`.
This then flags if there is a suggested major release, and if so,
rejecting it.
Co-authored-by: Claude Opus 4.8 (1M context) <jamie.tanna+claude-code@mend.io>
* refactor(manager/pixi): extract shared pixi.lock update helper
* test(manager/pixi): cover shared pixi.lock helper directly
Add a dedicated lockfile.spec.ts that exercises updatePixiLockfile
directly (gate, package-file write branch, lockfile maintenance,
unchanged, constraint pass-through, and error handling), and slim the
pixi and pep621 call-site specs down to their own behavior: how each
derives the pixi constraint and that they delegate to the shared helper.
* feat(managers/pep621): update pixi.lock if present
* test(managers/pep621): cover pixi requires-pixi from workspace table
* refactor(manager/pixi): extract shared pixi.lock update helper
* test(manager/pep621): use arrange-act-assert spacing in pixi tests
* refactor(manager/pixi): revert shared pixi.lock helper extraction
Move the extraction of the shared pixi.lock update helper into a
follow-up PR, as requested in review. The pep621 pixi processor and the
pixi manager again carry their own lock-update logic.
This reverts commit 743db204f2.
* feat(manager/pep621): gate pixi.lock updates behind allowedUnsafeExecutions
`pixi lock` can execute arbitrary code from conda package hooks, so the
pep621 manager now only updates `pixi.lock` when `pixi` is included in the
global `allowedUnsafeExecutions` option, following the same pattern as the
`mise` manager. When `pixi` is not allowed, PEP 621 dependencies in
`pyproject.toml` are still updated but `pixi.lock` is left unchanged.
https://pixi.prefix.dev/latest/security/#4-treat-package-hooks-as-code-execution
* feat(manager/pixi)!: gate pixi.lock updates behind allowedUnsafeExecutions
The pixi manager runs `pixi lock`, which can execute arbitrary code from
conda package hooks. Like the pep621 manager, it now only updates
`pixi.lock` when `pixi` is included in the global `allowedUnsafeExecutions`
option. When it is not allowed, the package file is still updated but
`pixi.lock` is left unchanged.
https://pixi.prefix.dev/latest/security/#4-treat-package-hooks-as-code-execution
BREAKING CHANGE: The `pixi` manager no longer updates `pixi.lock`
automatically. To keep `pixi.lock` updated, add `pixi` to the global
`allowedUnsafeExecutions` option.
feat(manager/pixi): gate pixi.lock updates behind allowedUnsafeExecutions
The pixi manager runs `pixi lock`, which can execute arbitrary code from
conda package hooks. It now only updates `pixi.lock` when `pixi` is
included in the global `allowedUnsafeExecutions` option, following the same
pattern as the `mise` manager. When `pixi` is not allowed, the package file
is still updated but `pixi.lock` is left unchanged.
https://pixi.prefix.dev/latest/security/#4-treat-package-hooks-as-code-execution
Convert SSH-style template URLs to their HTTPS equivalent when
constructing the packageName for the git-tags datasource lookup,
mirroring what the git-submodules manager does. This allows the
lookup to be authenticated via hostRules credentials on setups
which access the Git host over HTTPS only.
The answers file itself keeps the original URL, so local
'copier update' runs by developers continue to use SSH.
Discussed in #44528
* fix(github): include commitTrailers in platform-native commits
The GitHub platform-native commit path (platformCommit) recreates the
commit via the REST API using only message, so trailers from
commitTrailers / :gitSignOff were dropped even though prepareCommit
wrote them into the local commit.
* test: use codeBlock for multi-line commit trailer expectations
* Remove unnecessary comment
* refactor(gerrit): format commit message with shared helper
Use formatCommitMessage for Gerrit reserved trailers so the final
message is built the same way as the git and GitHub platform-native
paths, then clear trailers so prepareCommit does not append them twice.
* Revert "refactor(gerrit): format commit message with shared helper"
This reverts commit d230fa3802.
* refactor(git): fold commit trailers into the message before scm
Remove CommitFilesConfig.trailers so platforms only ever see a fully
formatted message. Workers call formatCommitMessage once; prepareCommit
and GitHub platform-native commits pass message through as-is. Gerrit
parses the existing trailer block to merge Renovate-Branch/Change-Id.
* refactor(git): drop formatCommitMessage helper
Trailers are already folded into message at the worker boundary, so the
shared formatter only re-joined strings. Inline that at the few call sites
and keep splitCommitMessage for Gerrit's reserved-trailer merge.
* revert: keep the minimal commitTrailers platform-native fix
Drop the later refactors (fold trailers into message, Gerrit changes,
splitCommitMessage). Keep formatCommitMessage shared by prepareCommit
and GitHub platform-native commits only; Gerrit is unchanged.
As found with recent changes to the Terraform manager, although we
generally have `lockFileMaintenance` being executed by an external
package manager being invoked by `exec(...)`, there are a few package
managers that do not do so.
To make it very clear how this happens, we can add a new field to the
Manager API, which will provide a means to document this.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fix(datasource/go): resolve sourceUrl from goproxy Origin
Use the Origin field from the existing @latest proxy response so vanity
modules get a sourceUrl without a go-get request to the vanity host.
* Rework some comments
* Update lib/modules/datasource/go/releases-goproxy.spec.ts
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
---------
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
* fix(gerrit): use max available Code-Review vote value for autoApprove
* Update lib/modules/platform/gerrit/scm.ts
Co-authored-by: Felipe Santos <felipecassiors@gmail.com>
* refactor(gerrit): extract Code-Review label name into a constant
* fix(gerrit): skip Code-Review vote and warn if label is not defined on project
* test(gerrit): restore Code-Review+2 auto-approve test with a defined label
* docs(gerrit): shorten getAutoApproveLabelValue() comment
* fix(gerrit): use static log message with metadata object for logger.warn
* refactor(gerrit): extract GerritLabels type alias
---------
Co-authored-by: Felipe Santos <felipecassiors@gmail.com>
Jamie Tanna