As part of the addition of the new Enrichment modules, we should perform
a prefactor that'll introduce helper methods that can be used across
both GitHub and OSV Vulnerability Alerts.
Because each module uses a slightly different input (Datasource ID or an
"Ecosystem" according to OSV) we need to handle both types of inputs.
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
* refactor(lint): extract custom oxlint rules into separate files
Split `tools/lint/rules.js` into one file per rule under
`tools/lint/rules/`. Also simplify `test-root-describe` with
early-exit guard clauses.
* feat(lint): add `enforce-ts-extension` oxlint rule
Add a custom JS-based oxlint rule that enforces `.ts` extensions on
local imports. The rule catches two problems:
- `.js` extension used instead of `.ts` (auto-fixable)
- missing file extension entirely (report only)
Checked locations:
- static import/export declarations
- dynamic `import()` expressions
- vitest module APIs: `vi.mock`, `vi.doMock`, `vi.unmock`,
`vi.doUnmock`, `vi.importActual`, `vi.importMock`
Both relative paths (`./`, `../`) and path aliases (`~test/`)
are treated as local. Package imports are ignored.
Also fixes 26 pre-existing violations across 18 spec files.
* Update tools/lint/rules/enforce-ts-extension.js
Co-authored-by: Anne Stellingwerf <1637358+astellingwerf@users.noreply.github.com>
---------
Co-authored-by: Anne Stellingwerf <1637358+astellingwerf@users.noreply.github.com>
* feat(onboarding): make `Add your custom config to ...` more prominent
As part of work to improve the Onboarding flow as part of larger repos,
we noticed that the `Add your custom config to ...` comment may be
missed.
We can make this more prominent by moving it up to the top of the PR.
* fixup! feat(onboarding): make `Add your custom config to ...` more prominent
* test(pr): add test coverage for `automergeSchedule`
* test(pr): validate full `Schedule` text
As part of a future change, we'll be modifying this, so we should
clarify the exact behaviour.
* feat(pr): break `Schedule` definition over multiple lines
To provide a more readable set of `schedule` and `automergeSchedule`
configuration options, we can break these over multiple lines, which
makes it clearer where there are multiple schedules that may apply at
a given time, as well as making it clearer between branch creation vs
automerge, which isn't necessarily clear.
* feat(pr): show cron syntax in code blocks
As it can make it clearer, as well as avoiding potential interpretation
as Markdown.
* fix(pr): ensure enough whitespace between elements
Although it's unlikely to hit our currently used Platforms, it's worth
making sure we do it right.
* test: add additional case for attestation changes
* fix: correctly warn when an attestation is missing
As noted in #37258, when a package registry had previously seen an
attestation for authenticity of a given package release, Renovate should
warn if future updates then lose authenticity.
Our previous attempt at this didn't quite pass around the current
package's attestation, which results in no warnings.
Given recent supply chain attacks where an attestation was removed (such
as Axios in MSC-2026-3522), we should make sure that this logic does
work correctly, and flags to our users.
In the future, we'll add more checks and a failing status check.
By introducing `hasAttestation` in the `LookupUpdate`, this can now be
matched on with `matchJsonata`, as well as providing visibility in the
`packageFiles with updates` log line.
* fixup! fix: correctly warn when an attestation is missing
> Run `pnpm run jest
> lib/workers/repository/process/lookup/index.spec.ts` and handle any test
> failures - the implementation is correct, so update the tests
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* test: clarify that we don't check for intermediate releases
Which we'll look to improve as part of future changes.
* chore: fix typo
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
As a means to make the dry-run functionality a little more useful, we
can log out what commit(s) a given Renovate run would have created
outside of Dry Run.
Because the meta key `contents` is automagically replaced with
`[contents]`, we need to move this into a new field, `rawContents`.
This can also lead to longer lines being output, but provides additional
utility that we've had requests for before.
As we continue to be more careful with our environment variable usage,
we should make sure it's not possible to ever have a clash.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
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>
* chore(autodiscover): log options being filtered
As a way to provide more debuggability, we can log the options we're
going to be filtering with.
* Update lib/workers/global/autodiscover.ts
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* fixup! Update lib/workers/global/autodiscover.ts
* fixup! Update lib/workers/global/autodiscover.ts
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
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>
As noted in #41551, when i.e. a `config.js` specifies the
`repositories` to run against, with specific configuration for each
repo, this is silently overridden by the CLI passing command-line
arguments.
Until #41551 is complete, we can introduce a warning log to surface this
to self-hosted users who may be unaware of this behaviour.
Co-authored-by: Claude Sonnet 4.5 <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