* fix(lint): use `parseInt` over `Number`
As a code review comment that comes up every so often, we can add a
linting rule to enforce this check.
This also fixes any existing usages.
As this could be breaking, we can release it as a `fix`.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fixup! fix(lint): use `parseInt` over `Number`
* fixup! fix(lint): use `parseInt` over `Number`
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
When certain meta fields are logged, we pull them out of the meta fields
and into the log line, such as:
DEBUG: Branch is not pending, removing pending upgrades (branch="renovate/express-4.x")
However, this also would affect non-string values such as:
DEBUG: Git operations statistics (branch="[object Object]")
This only affects the "pretty" logs, but would mean no `branch` metadata
appears.
Instead, we can only include them when they're a string.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As part of future changes, we need to correct the stringification logic
when `branch` is an object.
While looking at this, we noticed that `dependencies` is - likely - an
array of items being handled by `.toString()`ing them.
However, there's no existing cases in the codebase of this behaviour, so
we can remove it from `metaFields`.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As part of future changes, we need to correct the stringification logic
when `branch` is an object.
Before we do this, we can make sure we have full coverage of the
existing behaviour.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
fix(gomod): handle bare ../ replace paths in gomodTidyAll
When a go.mod file uses a replace directive pointing to the parent
directory with no sub-path (e.g. `replace example.com/root => ../`),
gomodTidyAll would silently skip running `go mod tidy` on that module
and any of its dependents.
The root cause was in the `localReplace` regex where the localPath
capture group used `\S+` (one or more non-whitespace), so `../` —
with nothing after the slash — was never matched. Only paths like
`../subdir` were picked up.
Changing `\S+` to `\S*` allows zero-or-more trailing characters,
so bare `../` and `./` now parse correctly and the dependency graph
is built properly.
* feat(presets): add @oxlint/* packages to packages:linters
Groups oxlint plugin packages together with oxlint itself.
* feat(presets): add @oxlint/plugins to monorepo:oxlint
* test(presets): update linters snapshots for @oxlint/**
`fixParsedRange()`'s `ordValues` array is only populated for a bare
(operator-less) segment when it's adjacent to `||`.
Any other bare segment throws earlier at `ordValues[i].includes('||')`
before either of these branches can be reached, so a falsy, non-`||`
`operator` is unreachable in both `fixParsedRange()` and `bumpRange()`.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
The `else if (gitRefsMatch.repoName)` branch was unreachable, so we can
simplify this check.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* feat(http/bitbucket): warn when an endpoint announces a deprecation
To highlight to a self-hosted administrator when they are using
deprecated/removed functionality, we can look for i.e.
sunset: Fri, 21 Aug 2026 00:00:00 UTC
deprecation: @1771545600
link: <https://developer.atlassian.com/cloud/bitbucket/changelog#CHANGE-3071>; rel="deprecation"; type="text/html"
This provides visibility into a soon-to-be-removed piece of
functionality, and should allow us to catch these deprecations more
centrally.
We make sure to log them - as a WARN - once, and with ISO8601 dates for
readability.
If we can't parse either `sunset` or `deprecation`, we log them as-is,
so we don't accidentally remove any necessary context.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
* fixup! feat(http/bitbucket): warn when an endpoint announces a deprecation
* fixup! feat(http/bitbucket): warn when an endpoint announces a deprecation
Co-Authored-By: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
As part of follow-up changes, we'll want to check the response's
headers, which requires we have an additional hook that we can use.
By default, this is a no-op.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
To surface the deprecation or removal of features by Bitbucket Cloud,
there may be an error body such as:
{
"type": "error",
"error": {
"message": "CHANGE-3071 - Functionality has been deprecated",
"detail": "Please read the changelog entry for more details.",
"data": {
"announcement_url": "https://developer.atlassian.com/cloud/bitbucket/changelog#CHANGE-3071"
}
}
}
To make it more visible to a self-hosted administrator that they're
using deprecated/removed functionality, we can elevate this to a WARN
log line, if there is an `announcement_url`.
We make sure to handle both parsed JSON response bodies and a raw string
body used for other requests.
To reduce noise to a self-hosted administrator, we can log this once per
run.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
On 2026-02-20, Atlassian announced that they would be removing the
native issue tracker in Bitbucket Cloud[0].
As of 2026-08-24[1], this change is now complete.
When Renovate attempts to update an existing Dependency Dashboard Issue,
we see:
DEBUG: GET https://api.bitbucket.org/2.0/repositories/some/repo/issues?q=... = (code=ERR_NON_2XX_3XX_RESPONSE, statusCode=410 retryCount=0, duration=87)
WARN: Error finding issues
And when trying to create one, we see:
DEBUG: findIssue(Dependency Dashboard)
DEBUG: Issues are disabled - cannot findIssue
Because it's not possible - until #20568 - to use another source for
Issues on Bitbucket Cloud, we need to remove support for the Dependency
Dashboard.
When we do try and interact with them, we can DEBUG log as to why it's a
no-op (similar to `platform=bitbucket-server`), and reference the deprecation.
As we now don't touch Issues, we can remove the additional permissions
that were previously required.
As there are no longer Issues, we can remove `has_issues` from our
types.
As well as the Dependency Dashboard, this also means that i.e. Config
Warning Issues are no longer available.
[0]: https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3071
[0]: https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3401
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
* feat(manager/github-actions): add `workflow` depType for reusable workflow calls
A job-level `uses:` pointing at `owner/repo/.github/workflows/<file>.yml@<ref>`
calls a reusable workflow rather than running an action, but both got the
`action` depType, so `matchDepTypes` could not tell them apart.
Give a reference whose sub-path is exactly `.github/workflows/<file>.yml|.yaml`
the new `workflow` depType. Every other sub-path, such as
`github/codeql-action/init`, stays an action.
The existing depType-keyed sites now accept both values, so nothing else
changes behaviour: the `actions.lock` file records reusable workflow calls too,
and `helpers:pinGitHubActionDigests` pinned them before this split.
* Apply suggestions from code review
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
As noted in #43761, we had recently set `CI=true` for the Renovate and
Containerbase orgs on Mend-hosted apps due to a pnpm v11 requirement:
ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY Aborted removal of
modules directory due to no TTY
If you are running pnpm in CI, set the CI environment variable to
"true", or set "confirmModulesPurge" to "false".
Similarly in #43606, it was noted that we should do this for `mise lock`
to mark the workspace as "trusted".
Although we went with a different situation, there will be cases where
this is useful for tools being executed, for instance when we invoke `yarn`.
We also make sure to keep our documentation up-to-date as we add to the
specific overrides.
As part of follow-up changes, it was noticed that our mocking of
`getChildProcessEnv` means we're not seeing the actual environment
variables in our tests.
To make sure that future tests can check that `CI` is added as expected
by default, we can remove the mocking.
Co-Authored-By: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As noted in #43761, we had recently set `CI=true` for the Renovate and
Containerbase orgs on Mend-hosted apps due to a pnpm v11 requirement:
ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY Aborted removal of
modules directory due to no TTY
If you are running pnpm in CI, set the CI environment variable to
"true", or set "confirmModulesPurge" to "false".
Similarly in #43606, it was noted that we should do this for `mise lock`
to mark the workspace as "trusted".
Although we went with a different situation, there will be cases where
this is useful for tools being executed, for instance when we invoke `yarn`.
We also make sure to keep our documentation up-to-date as we add to the
specific overrides.
With help from Claude Sonnet and Opus to:
- perform some of the mechanical updates as part of this change
- ensure that the Docker sidecar always has `hardcodedProcessEnv` passed
into it
- catch a needed change to `exposeAllEnv` handling
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As part of future changes, we'll introduce additional values, and we
want to make sure that this is strictly catching that addition.
However, this drifts between CI and local builds, as in CI, `CI=true` is
set, so we can explicitly set it for now.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* feat(config): add `overrideDescription` option
Presets which extend many other presets used an `ignoreDeps: []` sentinel
to keep their own one-line summary in the onboarding PR instead of one line
per extended preset. Replace that hack with an explicit `overrideDescription`
option, which is consumed and removed while presets are resolved.
The resolved descriptions are unchanged. Repositories which set
`ignoreDeps: []` in their own config no longer lose all preset descriptions
in their onboarding PR.
* fixup! feat(config): add `overrideDescription` option
* fixup! feat(config): add `overrideDescription` option
* fixup! feat(config): add `overrideDescription` option
Adds a custom oxlint rule renovate/v8-ignore-no-count that flags the
count form '/* v8 ignore next <N> */'. The count is not honored by
vitest's ast-v8-to-istanbul hint parser, which captures only the
keyword (if/else/next/file); 'next' always exempts exactly the next
AST node. Trailing counts therefore suggest a line range that is never
applied and mislead readers.
The rule is autofixable (drops the count, preserving actual behavior)
and has been applied to all existing occurrences.
When using the "summary view", in the case we hit platform limits, in
Onboarding PRs or Reconfigure PR comments, we should prioritise the
"What to Expect" as it provides a more actionable "executive summary" of
what's needed in the repository.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* refactor(workers/repository): extract PR body template helpers for onboarding/reconfigure
As part of follow-up changes to reorder the "summary view", we need to
extract the core logic out for onboarding/reconfigure PRs.
Given the tests haven't needed to change, we can see this is a perfect
in-place rewrite.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fixup! refactor(workers/repository): extract PR body template helpers for onboarding/reconfigure
Adding existing missing coverage.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fix(vulnerabilities): scope Go stdlib OSV remediation to the `toolchain` directive
The module `go` directive was already excluded from OSV alerts, but the toolchain
rule still matched it via shared datasource/packageName and go-mod-directive ranges.
* fix(vulnerabilities): scope OSV remediation rules to the vulnerable depType
Remediation rules are generated per dependency. When that dep has a depType,
constrain the rule so it cannot match another dep that shares datasource and
packageName.
* fix(vulnerabilities): set matchDepTypes only for Go toolchain OSV rules
A generic matchDepTypes would stop an npm `dependencies` rule from also
matching `overrides` of the same package. Only the existing toolchain path
sets depType on the generated rule.
* feat(onboarding): improve wording of concurrency limits with PRs opened
When receiving an onboarding PR while using `prConcurrentLimit`,
`branchConcurrentLimit` or `prHourlyLimit` concurrency controls, users
may still receive a note such as:
> will create 189 Pull Requests
This isn't true, and can be surprising and/or worrying for a user who
may believe they're going to be swamped by PRs.
We can therefore improve this, to make it clearer how many will be
immediately raised, and how many will be raised over time.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* test(onboarding): reduce duplicated test setup
As a way to make it clearer what each test is actually testing.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As reported in #45357, changes in
116c3d610c caused a regression for cases
where an npm package had `homepage: [...]`.
We should restore the `catch(undefined)` and add a test to make sure
this isn't broken in the future.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
Joseph Petersen