* fix(gitlab): skip branch status when no pipeline found, retry after PR creation
On GitLab with MR pipelines, posting a commit status without a
pipeline_id causes GitLab to create an unwanted branch pipeline.
Skip posting the status in setBranchStatus() when no pipeline is found
after retries. Retry setting branch statuses after ensurePr() in the
with-pr block so that the MR pipeline created by GitLab can be found.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
* fix(gitlab): gate skip-status-without-pipeline behind experimental flag
Move the behavior that skips setting a branch status check when no
pipeline is found behind the RENOVATE_X_GITLAB_SKIP_STATUS_WITHOUT_PIPELINE
experimental environment variable. Without the flag, the original
behavior of always posting the status is preserved.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* test(gitlab): restore original 'sets branch status' test case
Keep the original test that verifies branch status is set without
the experimental flag alongside the new skip-behavior test.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix(docs): sort experimental env var headers alphabetically
Move RENOVATE_X_GITLAB_SKIP_STATUS_WITHOUT_PIPELINE after
RENOVATE_X_GITLAB_MERGE_REQUEST_DELAY to satisfy alphabetical
ordering requirement in self-hosted-experimental.md.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix(gitlab): address PR review comments for skip-status-without-pipeline
Use strict `=== 'true'` check for env var, update docs wording, and
add test coverage for the new experimental flag behavior.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com>
* fix(jsonata): updates when version and digest changed (#36461)
Cherry-picked from #38066 and fixed regression #38252.
Uses the test from #38298 to confirm the regression is not reintroduced.
* fix: review comments
Signed-off-by: Jalil David Salamé Messina <jalil.salame@gmail.com>
Change-Id: I6a6a69641345ca16b82a9e082aa1b19b13e267bf
* fix: issues introduced by branch update
I didn't resolve the merge conflict properly.
Signed-off-by: Jalil David Salamé Messina <jalil.salame@gmail.com>
---------
Signed-off-by: Jalil David Salamé Messina <jalil.salame@gmail.com>
With the current logs, there was no way other than inspecting the actual
PR to determine the PR labels. As a consequence, debugging PR labels
with a dry run was simply not possible. This makes more complex labeling
rules extremely hard to debug.
This commit adds the computed PR labels to the log output when actually
creating a PR as well as when performing a dry run.
feat(logging): include PR number when detecting existing branch PR
Include the PR number in debug log messages when:
- An existing open branch PR is found ("Found existing branch PR #123")
- A closed PR already exists ("Closed PR #123 already exists")
This aids debugging by making it easier to correlate log entries with
specific PRs when reviewing Renovate logs.
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
To make sure that we're using secure defaults, we can make sure that
this is off-by-default.
Self-hosted administrators will be able to turn this back in if they
wish.
* fix: `workingDirTemplate` must be relative to the repo root
The `postUpgradeTasks.workingDirTemplate` did not work correctly,
as the working directory is the directory where Renovate is executed.
Thus prepend the paths with `localDir`, i.e. the repository root.
* refactor: use the return value of ensureLocalDir
The function already expands the path.
When using `replacementNameTemplate` with Docker images that have pre-pinned
digests, the auto-replace logic was incorrectly entering the `currentDigestShort`
replacement branch even when the digest didn't need to be changed.
Since `currentDigest === newDigest`, the first digest replacement block was
skipped. But the `else if` checked only `currentDigestShort !== newDigest`,
which was true (e.g., "5fa2edb" !== "sha256:5fa2edb..."), causing it to replace
the short string with the full digest, corrupting the result to
"sha256:sha256:..." format.
The fix adds a guard condition to skip the `currentDigestShort` replacement
when the full `currentDigest` already matches `newDigest`.
Fixes#40169
As part of hardening the configuration around executing
`postUpgradeTasks` with `shell: true`, we can give self-hosted
administrators the opportunity to configure this.
This continues to be on-by-default to be non-breaking, but in the next
major version can be flipped to the safer option.
As part of future changes to ensure that `shell` is disabled by default,
we should first enforce this for our `postUpgradeTasks`, which are
user-controlled and are more likely to contain shell-interpolated
variables.
We need to add a new `shell` type to pass around, as it was previously
not optional.
As part of a future change, we'll add additional arguments, but don't
need to validate them in every test.
To make sure that it's clearer what these tests are validating, we'll
use `expect.objectContaining` to test a subset of the object keys.
* refactor: use unicode right-arrow for changes template
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* refactor: use unicode right-arrow for changes template
Signed-off-by: Adam Setch <adam.setch@outlook.com>
---------
Signed-off-by: Adam Setch <adam.setch@outlook.com>
This will make sure that we're calling it for each release being
skipped/continued with, so we're reducing the log lines for duplicate
dependencies across the codebase.
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* incorporate feedback
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* incorporate feedback
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* Update common.ts
* Update common.ts
* Update common.ts
---------
Signed-off-by: Adam Setch <adam.setch@outlook.com>
As noted in #37952, we've seen a significant increase in recent years on
a number of package ecosystems being targeted with supply chain security
attacks.
We're in a particularly strong position to improve the level of security
across the world by setting a default for `minimumReleaseAge` in the
`best-practices` config preset.
To do this, we can introduce a new preset,
`security:minimum-release-age` to house these recommended options.
We use new presets `security:minimum-release-age` and
`security:minimum-release-age-npm`, to allow consumers to utilise
`ignorePresets` to undo this configuration, if they so wish.
As a first step towards securing our users, we can set a default for
npm, which as a large ecosystem with an increased number of packages
that depend on other packages (compared to other ecosystems), has been a
more targeted area.
In the future, we can expand this for other managers, as it makes sense,
and as support is added for them to use `minimumReleaseAge`.
Closes#38457.
As part of future changes, where it's more important to know what
`updateType` is being filtered, we will want to have this information
output to the logs.
This also changes the log field outputting, as `depNames` no longer
makes sense now we have both `depName` and `updateType`.
* chore: debug log message when timestamp is optional
When setting minimumReleaseAgeBehaviour to optional
it is intended that packages that does not have a release timestamp
will get updated. Writing a warning to the console is spam for an
intentional setting.
* chore: re-add WARN log, once
To make sure that users are still aware, we can make sure a single
warning log message is emitted.
---------
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
* fix: do not modify # within codeblocks
* fix: parse fenced section in markdown
* add test
* Update lib/workers/repository/update/pr/changelog/release-notes.ts
* use re2
As noted in #38290, #38348, a "rough edge" of the current implementation
of `minimumReleaseAge` is that:
- if we have set `minimumReleaseAge` to apply to a given dependency
- and we have 3 dependencies that need an update
- 2 of which have a `releaseTimestamp` that is not yet "stable"
- 1 of which does not have a `releaseTimestamp`
The dependency update that does not have a `releaseTimestamp` will be
treated as "stable", and will receive an update immediately.
To make this a little more predictable, and explicit, we should add a
new configuration item, `minimumReleaseAgeBehaviour`, to control this
behaviour.
This adds the new configuration field, as well as making it available as
a strongly typed field in the codebase.
In the case that `minimumReleaseAgeBehaviour=timestamp-optional` is
being used, we will WARN on any packages that are being updated, but
maybe shouldn't be, as a way to proactively inform the user of possible
misconfiguration.
Closes#38290, #38348.
When performing lookups in Mend's Merge Confidence APIs, our contract
requires that we use the `packageName` not the `depName`.
In 9b7ae6aa98 and
b67eae2180 we made changes to make sure
that this wasn't the case, but we ended up missing a couple of cases.
As part of discussion in #38290, #38348 and #38324, the current
behaviour of `minimumReleaseAge` has been flagged as not particularly
great, as when we run with `minimumReleaseAge` enforced, a package that
does not return a `releaseTimestamp` will no longer be treated as
release that is bound by `minimumReleaseAge`'s checks to make it
pending.
As noted in the discussions, this can lead to cases where users are in a
"false sense of security", as they feel comfortable with
`minimumReleaseAge` in place, but it is not being enforced, only when
the `releaseTimestamp` is present.
Before we change this, we should add a test to document the existing
behaviour.
[0]: https://github.com/renovatebot/renovate/discussions/38290
[1]: https://github.com/renovatebot/renovate/discussions/38348
* fix(gerrit): pass config labels to commitAndPush
Pass the config labels to commitAndPush so they get properly populated
for gerrit.
This follows from https://github.com/renovatebot/renovate/pull/35900
which added label support for gerrit but didn't properly pass them
along in all places.
* test: fix tests
Fix tests
* test: extend commit test to ensure labels are passed
Extend the commit test to ensure labels are passed
* refactor: add comment indicating labels are needed only for gerrit
Add comment indicating labels are needed only for gerrit.
Florian Greinacher