As part of changes in #42142, I noticed that we didn't have any coverage
of how this was determined.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
When a `lookupError` occurs, it's currently unclear as to why the lookup
error occurred.
It seems to be more common in the Go ecosystem where a lookup error
occurs, and Renovate autocloses PRs, only to recreate them in a
future run.
To provide more useful debugging information to users, we can add the
actual `lookupError` string itself.
As `fileName` makes more sense (as it's not always a lock file we're
updating).
Also, if you set `fileName`, it would never actually output the
filename.
This renames the usages of `lockFile` to `fileName`.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
As noted in #41716, there are cases where a `depName` may be absent, but
a `packageName` is present.
We should handle this accordingly, and check for the `packageName`, and
only error if neither of these are set.
* feat(workers/repository): raise artifact error if `pending` version used in an update
When using Minimum Release Age, and a package manager that doesn't
support being told an explicit version to update to (#41624) it is
possible that an artifact update leads to a different version of a
dependency being used compared to what Renovate is expecting.
This can lead to, at best, a surprising PR update, and at worst, a
supply chain attack.
We should report these cases more explicitly with an Artifact Error, to
allow the reviewers to decide what to do with the changes.
To do this, we need to re-extract package files after an update, and
determine if any of the version(s) of that dependency are using any of
the `pendingVersions`.
This may be slightly breaking to users, which is why this is a `feat`
not a `fix`, but isn't so breaking that it's worth leaving until the
next breaking change .
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+github-copilot@mend.io>
* fixup! feat(workers/repository): raise artifact error if `pending` version used in an update
* fixup! fixup! feat(workers/repository): raise artifact error if `pending` version used in an update
* Update lib/workers/repository/update/branch/get-updated.ts
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+github-copilot@mend.io>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* feat(postUpgradeTasks): allow specifying `installTools`
As noted in #8111 and #41569, it is possible that when using
`binarySource=install`, you can execute a `postUpgradeTasks`' given
command without Renovate having the right tools installed, dependent on
the Manager used for the update.
To make it possible for users to indicate that they explicitly need
given tools (at a given `constraint`), we can introduce a new
`installTools` option which will allow specifying which tools +
constraints to use when invoking the `postUpgradeTasks`'s command.
Right now, we're not defining what the `installTools'` interior type is,
but leaving it open to extension.
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* docs: add examples for `toolVersions`
---------
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* 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>
As per request in #40091, we have cases where folks are using tools to
read or diff the `manager extract durations (ms)`
To improve this, we can make sure to perform a stable sort, by
alphabetically sorting our package manager names.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
* feat(vulnerabilities): add support for github-actions vulnerability alerts
* fix failed merge from main
* now for real
* review comments
* remove no longer needed assertion
refactor(libyears): clarify log messages are LibYear related.
As it can be a little confusing exactly where this log message is coming
from, otherwise.
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.
Jamie Tanna