The containous/traefik repository was renamed to traefik/traefik in 2020. GitHub still redirects, but PR release notes render the old organization name.
Some registries publish several tags for one version, e.g. Docker Hub has both 3.7.12 and v3.7.12 for the traefik image. Both survive datasource deduplication, which compares raw version strings, so the changelog renders the release notes once per tag.
* 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
renovate[bot]