* chore(workers/repository): report malicious packages before `packageFiles with updates`
As part of future changes, we may modify the `skipReason`s before the
update phase, which means that we should ensure these are correct before
logging out `packageFiles with updates`.
* chore(workers/repository): split malicious dependency checks
We will likely run into two specific cases of malicious dependencies -
you're currently using one, or you're receiving an update to one.
We should make these separate, explicit, cases so users are aware what
`malicious` actually means, and what the path forward is.
As part of future changes, we'll be introducing `skipReason: malicious`
against dependencies that have been found to be actively malicious.
Once we've looked up all our dependencies, we should then - centrally -
log any malicious package usages as a WARN, to highlight this to users.
As part of the addition of the new Enrichment modules, we should perform
a prefactor that'll introduce a shared helper for the how we translate
an "Ecosystem" according to OSV with a datasource that Renovate
understands.
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
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>
* 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>
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.
refactor(libyears): clarify log messages are LibYear related.
As it can be a little confusing exactly where this log message is coming
from, otherwise.
As part of future changes, we want to log the shallow configuration (the
full resolved configuration, but without any internal Renovate
configuration presets), where we'll want to note which presets have not
been merged in.
Before that, we can start with an initial refactor to indicate which
have been merged, and return them.
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.
As a means to provide more insight into how long package manager lookups
take when using instrumentation, we can wrap the fetching of updates in
a trace per manager.
As part of ongoing work to improve OpenTelemetry instrumentation of
Renovate in #38609, we can instrument our branch creation with the
branch name (and relevant Semantic Convention attributes) for
visibility.
When calling `extractDependencies`, we actually perform both `extract`
and `lookup` splits. However, we are instrumenting the whole method call
as the `extract` split, which results in incorrect tracing data.
To correct this, we can wrap the specific code responsible for the
extraction into `extract`, and then the separate code for `lookup`
accordingly.
This also makes sure that `emptyExtract` sets repository splits.
Refactors `getNewValue` logic to replace it with an optional
`getPinnedValue()` where rangeStrategy=pin. This way each versioning
module doesn't need to add and test extensive "pin" logic.
This should not be breaking, but out of an abundance of caution, we'll
mark it as such.
* 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>
* Optimize version filtering logic in filterVersions and lookupUpdates functions
* Simplifies version filtering optimization to cover conditions by existing tests.
* Further reduction of versioning API usage.
* Keeping compatibility of exported function filterVersions()
* use branchPrefix if multiple base branches expected
* fix test
* fix coverage
* apply suggestions
* apply suggestions
* use utility fn
* refactor tests
* fix test
* major overhaul: use baseBranches field internally
suggested by @secustor
* refactor: cleanup
* test: use better descriptions
* add tests
* fix logic
* fix test
* exclude unlisted versions when finding latestStable
---------
Co-authored-by: Rhys Arkins <rhys@arkins.net>
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.
Jamie Tanna