As found in #40942, we've been seeing increased memory usage by pnpm and
Yarn in recent months on Mend-hosted apps.
As a way to provide more control to test + validate fixes, as well as
provide self-serve for other environments, we can allowlist
`PNPM_WORKERS`/`PNPM_MAX_WORKERS` in both the "basic env vars" and the
allowed `global:safeEnv`.
* feat(manager/renovate-config): extract `constraints`
As noted in #41571, it would be useful to detect and suggest updates
when specifying `constraints` in Renovate config, where it's a known
tool we provide versioning information for.
We can extend our existing `renovate-config` manager to add support for
`constraints` that are known Containerbase tools.
We can support top-level `constraints` as well as `constraints` inside
`packageRules`.
* refactor(renovate-config): remove nesting
* feat(vulnerability): Add vulnerability alerts to deps-end + lein
deps-edn and lein both essentially use maven upstream for several
packages. Some packages come from clojars directly but others are
typical java packages. If there is an OSV alert for a maven package
however, it will not propagate to the deps-edn or lein dependency update
from renovate. This tries to adjust that so that clojure can derive
dependency alerts from maven as well so that those dependencies are
treated the same way.
* chore: Code review feedback
* chore: Make ecosystem to datasource one to many
Technically datasource to ecosystem was already many to one in a way, as
maven appeared in the values twice. Once for clojure and once for maven
itself. This changes it so that the ecosystem to datasource is the same
way and looking up by ecosystem you will get multiple datasources
(should match the map above the modified code).
Then to make this work, instead of keying off of datasource for
vulnerabilities we key off of ecosystem so that all of the datasources
that are part of that ecosystem inherit the vulnerabilities for the same
dependency.
* chore: Tweaking to try to force CI/CD retry
* feat(update-date-cache): implement caching for branch update dates
* Try fix coverage
* Fix some test style inconsistencies
* Fix coverage
* Fix test
* Fix test testing the same path
As part of future changes in #42567 to surface the `constraints` of a
given Go module, we should first extract the constraints from the
package file.
To make this simpler for users, we can make sure we extract these at
parse time:
- the `toolchain` directive becomes the `golang` constraint, which
matches the `golang` tool name already in use for Containerbase
- the `go` directive becomes a new `%goMod` constraint, which keeps it
separate from the version of the Go toolchain actually used to run, as
well as clearly not for the Go tooling, or something that
Containerbase knows about
- we make sure to extract it with a SemVer range that can then be used
to ensure that, in future changes, using `constraintsFiltering=strict`
will allow filtering releases from the Go datasource based on this
constraint.
- because we're now returning the `constraintsVersioning`, we need to
make sure this is part of our types
* fix(validation): validate `constraints`
To provide better coverage for our users of what is a valid option for a
`constraints` value, we can validate the overall format of the
`constraints` block, as well as the given names of constraints.
Where we have a Tool defined, we can use the default versioning for that
Tool to validate the constraint's value.
For now, both the validation of the `constraints`' value, and the
validation of `constraints`' names will be a warning, but in the future
may be made an error.
* chore(validation): remove check for `compatibility`
As this was renamed in #7308. It's been long enough since then that we
can remove this check.
* chore(validation): add logger in `else` case
For coverage fix, and also to provide insight when this does happen
* fixup! chore(validation): add logger in `else` case
* fixup! chore(validation): add logger in `else` case
* key
* coverage
* Remove duplicate function
As it's been pulled in via another PR.
* fixup! docs(constraints): document the possible `constraints` and `installTools` (#42837)
As it can't be `undefined`.
* test: coverage
And more whitespace to make it clearer they're two separate `if` blocks.
* typo
* typo
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* fix(gerrit): defer change creation to `createPr()`
Signed-off-by: Felipe Santos <felipe.santos@ericsson.com>
* Refactor hashtags handling
* Add prTitle to all missing commitAndPush()
* Fix gerrit tests
* Add warning when prTitle is set in updatePr
* Remove now useless labels from commitAndPush
* Fix gerrit client coverage
* Fix gerrit scm coverage
* Fix rebase coverage
* Improve TODO about assignees
* Fix formatting
* Fix review comment
* Extract to a pushForReview function
* Fix after #41382
* Fix onboarding
* Cleanup code
* Fix ESLint
* Fix tests
* Restore gitRetry for git.merge
* Fix tests
* Simplify hashtags code
* Delete pendingChangeBranch in pushForReview()
* Fix test name
* Remove unnecessary test comments
* Improve test name again
* Fix another test name
* Delete local branch in Gerrit SCM
* Add test for deleting pending branch
* Add tests for pushForReview()
* Fix test case name
* Improve another test name
* Fix another small test inconsistency
* Fix some code style issues
* Use isUndefined instead
* Fix one small test style issue
---------
Signed-off-by: Felipe Santos <felipe.santos@ericsson.com>
* docs(constraints): list the possible `constraints` and `installTools`
Now we have a stronger type for what a valid tool constraint is, and
what additional constraints are, we should be very explicit with what
each option is, and specify them in the `constraints` as well as our
`installTools` docs.
* test: add coverage
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Instead of inline documentation with JSDoc, we can use an optional
`description` field that can be accessed programatically.
This means the `description` can also be added to our JSON Schema for a
Tool, or be the only output when a non-Tool constraint, as the
description for non-Tools are more clear than the autogenerated text.
We can make sure we continue to export the known names, as well as the
full definitions.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As noted in #41953, the introduction of `getBranchUpdateDate` did not
take into account the use of a repository cache.
When using a repository cache, the repo is not cloned until it is needed
(and various metadata is used from the cache instead).
However, when using a cache (with a repo not yet cloned) this results in
`getBranchUpdateDate` failing (and a debug log appearing).
We can instead handle this by performing a repo sync at this point.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs(json-schema): add `constraints` and `installTools`
This requires `toolNames` and `additionalConstraintNames` are exported
for use.
* fixup! docs(json-schema): add `constraints` and `installTools`
* chore(types): correct JSDoc
* chore(types): add missing `ConstraintName` enforcement
* fixup! chore(types): add missing `ConstraintName` enforcement
By simplifying this case, which should never happen, as the types
wouldn't allow it.
* chore: reorder for typechecking simplicity
* fixup! chore(types): add missing `ConstraintName` enforcement
* fix(package-rules): correctly merge `force.enabled`
As noted in #42666, after changes in
f8b4477335, we're skipping vulnerability
alert PRs when using the `security:only-security-updates` preset.
This happens because the `enabled=false` that exists on the all
dependencies are not correctly merged into the `force` config in the
`vulnerabilityAlert` update.
To fix this, we need to take `force.enabled` into account when merging
config options.
To slightly improve the type checking, we can also make sure that
`removeMatchers` knows that `force` is field we want typed, too.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* chore(package-rules): simplify condition
As we don't actually need to take into account whether the option is
currently enabled, as we can make sure the `skipReason` and `skipStage`
are always deleted if we're enabling the update.
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fix(workers/repository): cleanup localDir before recursive retry after automerge
* add test for failed directory cleanup
* fix(git): don't pass extraCloneOpts to ls-remote when local clone exists
* refactor(cache): Remove obsolete compress flag
* Update terminology in package cache tests
Replace references to "current format" in test descriptions with
explicit mentions of payload values and expiries. Rename the
`compressedValue` variable to `payloadValue` to match the updated
descriptions.
* feat: timing statistics for getReleases
Adds collection and reporting of timing statistics for
`datasource.getReleases()` calls. Each call records the datasource, registryUrl,
packageName, and duration. The intent is to visibility into where
renovate is retrieving release information and how long that might take.
The report consists of a nested data-structure that provides increasing
detail as we descend datasource, registryUrl, and packageName.
The full report is logged at trace level
`getReleases statistics with packages`.
A summary report including only datasources and registryUrls is logged
at debug level `getReleases statistics summary`.
* add GetReleasesSpanProcessor
- Re-instrument getReleases calls using open telemetry.
- Adds GetReleasesSpanProcessor, which can adapt
`getReleases` spans to GetReleasesStats.
* fixup instrumentation tests
* pr feedback
* pr feedback: naming
* pr feedback: comments
* test(util/git): add test coverage for `X_CLEAR_HOOKS`
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
* fix(util/git): allow setting `config.hooksPath`
Since simple-git 3.35.2's update in #42588, the setting of
`config.hooksPath` is marked as "unsafe", and does not allow setting
this configuration.
This only affects users who specify the experimental self-hosted config
option, `RENOVATE_X_CLEAR_HOOKS`.
However, the primary user of this is Mend-hosted Renovate which, as
noted in #42628, resulted in all jobs failing to run.
We can instead conditionally set the `allowUnsafeHooksPath`
configuration if we're running with `RENOVATE_X_CLEAR_HOOKS`.
We need to refactor our test to make sure that we're re-initialising
`git` at the point the `RENOVATE_X_CLEAR_HOOKS` is set.
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
* feat(PackageCacheFile): add a in-memory expiry map
This allows for faster expiry lookup, which makes for the bulk of
the loop on destroy(). Note that this doesn't remove the overhead
of looping through all entries, but at least doesn't load the
data from disk with a deserialization.
* deps: add lru-cache
* limit the size of the in-memory object
* remove benchmark
* chore(types): add a strong type for `ToolName`s
Until #41849, we can use our local definitions of the tool names that
Containerbase supports by extracting out a `ToolName` type.
* fixup! chore(types): add a strong type for `ToolName`s
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* fixup! fixup! chore(types): add a strong type for `ToolName`s
* no-never
* simplify
* coverage
* sq
* warn
* sq
* fixup! sq
* sq
* fixup! sq
---------
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
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>
* fix(http): fallback to github hostType for GHE platform endpoint
When running against GitHub Enterprise Server, datasources not listed
in GITHUB_API_USING_HOST_TYPES (e.g. github-digest) fail to authenticate
because the existing fallback only covers api.github.com URLs.
This adds a host-matching fallback: when the active platform is github
and the request URL targets the same host as the configured endpoint,
credentials from the github hostType rule are applied.
* Refactor
* Fix
* feat(datasource): add elm-package datasource
* refactor(elm): inline test fixtures
* fix(elm): correct import ordering in test file
* fix(elm): use zod/v3 import to match codebase conventions
* refactor(elm): rename types.ts to schema.ts
Follow project convention of using schema.ts for zod schema files.
* test(elm): add test for invalid JSON response
Use v8 ignore if directive and add test covering the null result
path when the API returns invalid JSON.
* refactor(elm): remove unreachable null check
* test(elm): add test for default registry URL fallback
* refactor(elm): guard against missing registryUrl instead of fallback
* fix(elm): handle ZodError gracefully instead of throwing
* feat(elm): add package cache for elm-package datasource
Michael Kriese