* refactor(onboarding): return repository result from ensureOnboarding
Rename ensureOnboardingPr to ensureOnboarding and have it return a new
'onboarding' RepositoryResult. renovateRepository now branches on
repoIsOnboarded, so exactly one of ensureOnboarding/updateRepo produces
the repository result and the non-null assertion on the update result
(TODO #22198) is no longer needed. updateRepo/update no longer return
undefined for non-onboarded repositories.
* refactor(onboarding): keep ensureOnboardingPr name
When Go updates dependencies using i.e. `go get` or `go mod download`,
it uses Minimal Version Selection (MVS)[0], which takes the lowest
version available from the given packages.
In the case of an updated dependency, in practice this means that Go
will chose the version of an indirect (transitive) package dependency as
the version that the updated package points to in their `go.mod`, which
must be older than the updated package, as the updated package has only
just been updated.
This protects against cases in other ecosystems where an unpinned
transitive dependency can be pulled by an updated package, potentially
bypassing `minimumReleaseAge`.
However, I can imagine there may be some questions about this, so we can
preemptively add a note into the `Artifact update notice` when
`minimumReleaseAge` is set.
[0]: https://go.dev/ref/mod#minimal-version-selection
As noted in #36073, having support for the different protocols for
exporting OpenTelemetry data would be useful, especially if this is
leading to users seeing issues when they have auto-injected
configuration being set.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fix(github): treat graphql_rate_limit as rate limiting
GitHub answers a spent app-installation budget with a GraphQL error carrying
code graphql_rate_limit, which neither call site recognised: the repository
query reported platform-unknown-error, and app authentication reported
Init: Authentication failure. Both readings send the user looking for a
problem that is not there, and neither is retried the way rate limiting is.
The two shapes are now recognised in one place and both call sites use it.
* fix(github): propagate GraphQL rate limits
* fix(github): preserve GraphQL response contract
---------
Co-authored-by: Sergei Zharinov <zharinov@users.noreply.github.com>
Refs #45216
The object counterpart to `prefer-coerce-array`: `x ?? {}` becomes
`coerceObject(x)`. The rule flags a `??` whose default is a bare `{}`
literal, so a populated default or an asserted `({} as Foo)` still
passes; a `x ?? y ?? {}` chain maps onto `coerceObject(x, y)`.
Every hit across `lib/` converted cleanly, so no disable comments were
needed.
* refactor(linters): add prefer-coerce-array rule
Refs #45217
`x ?? []` and `coerceArray(x)` say the same thing, but only the second
one is searchable and consistent. The rule flags a `??` whose default is
a bare `[]` literal; a non-empty default or an asserted `([] as Foo[])`
still passes.
Applying it across `lib/` surfaced three spots the helper cannot cover,
which keep `?? []` with a disable comment or a narrower fix:
- `package-files.ts` destructures a tuple, which `coerceArray()` widens
- `generate.spec.ts` defaults `matchAll()`, an iterator rather than an array
- `mise/upgradeable-tooling.ts` declares a `Record` return, so its
`?? []` fallback was wrong to begin with and becomes `coerceObject()`
* refactor(platform/github): hoist the GHE version header lookup
`Object.entries(...).find()` returns a tuple, and defaulting it with
`?? []` only to destructure the second element reads as an array
default when it is not one. Name the found entry instead, which drops
the `?? []` rather than routing a tuple through `coerceArray()`.
fix(manager/copier): set isExecutable on added and modified files
Detect the owner execute bit on files written by copier update and
propagate it as isExecutable on the returned file additions, so
committed files keep their executable flag.
* test: replace manual process.env mutation with vi.stubEnv
Enable Vitest's `unstubEnvs` so env stubs are reverted automatically
before every test, and convert the manual `process.env.X = ...` /
`delete process.env.X` pairs in specs to `vi.stubEnv()`.
This removes the hand-written `afterEach` cleanup blocks and the
`const OLD_ENV = process.env` / `process.env = { ...OLD_ENV }`
save-restore dance, which silently leaked state between tests when a
test set a variable without a matching delete.
Left as-is (incompatible with `unstubEnvs`, which unstubs before each
test, not after):
- module top-level env writes (cocoapods, gomod, post-update, pip-compile
and bundler artifacts specs)
- `beforeAll` env writes -- the two in `util/http` moved to `beforeEach`
* test: stop asserting on ambient environment variables
Three specs asserted on values that the surrounding environment can
override, so they only passed on a machine that happened not to set them:
- `util/exec/env`: `getChildProcessEnv()` forwards every entry of
`basicEnvVars`, but the spec only seeded a subset. Any other forwarded
variable that was set ambiently (e.g. a lowercase `http_proxy`) leaked
into the `toEqual` assertion. Clear all of them first.
- `util/git/index`: `process.env.GIT_SSH_COMMAND` deliberately overrides
the default that the two env-inheritance tests assert on. Clear it.
- `logger/pretty-stdout`: the colorized level strings are built at import
time, so the `beforeEach` setting `FORCE_COLOR` could never affect them
-- it was dead code, and the test silently assumed a terminal without
colour support. Derive the expectation the same way the module does.
* test(datasource/nuget): use a throwaway cache dir for nupkg downloads
The `determine source URL from nupkg` tests do not mock the filesystem,
so they really wrote downloaded packages into a fixed `/tmp/cache` path.
That fails wherever the system tmpdir is not writable, and two checkouts
running the suite at once would share the same directory.
Use `tmp.dir({ unsafeCleanup: true })` and clean it up afterwards, which
is the pattern the other specs that touch disk already use.
* feat(lint): add renovate/prefer-stub-env rule
Enforces in specs what the migration to `vi.stubEnv` established:
- assigning to or deleting `process.env.X` inside `beforeEach`, `afterEach`,
`it` or `test` is reported, with a fixer that rewrites it to `vi.stubEnv()`
- module scope, `describe` bodies and `beforeAll` / `afterAll` are left alone:
`unstubEnvs` reverts stubs *before* each test, so a stub created there is
gone by the time the first test runs, and those must keep assigning directly
- replacing the `process.env` object is reported everywhere and never fixed.
`vi.stubEnv()` captures the original object when the worker starts, so after
a reassignment its deletes silently target the old object
The rule found 28 further violations in specs the earlier sweep missed, since
that one was anchored on `delete process.env`. Twelve were auto-fixed; the
rest replaced `process.env` wholesale and are now `clearEnv()` from test/util.
`util/exec/index.spec.ts` opts out with a comment: it asserts on the whole
child env, and `vi.stubEnv()` cannot express that because it maps `PROD`,
`DEV` and `SSR` onto '' instead of deleting them.
feat(changelog): stop fetching PR changelog entries when we're at platform limits
A regular issue that we see across Renovate users - often with
packages like traefik (#45482) - are that a large number of
changelogs needing to be fetched can lead to a slow run (at best) or
a full out-of-memory error (at worst).
As noted in #45501, as a follow-up to #45500, we can stop fetching
more entries for the changelog generation by checking Platform
limits for a given Pull Request.
We can ignore `fetchChangeLogs=branch`, because users opting into
that behaviour are hopefully aware that adding their changelogs will
be sufficiently large.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As noted in #45500, we want to refactor how changelogs work to fetch
them in newest-first order.
This will allow in future changes to stop fetching changelogs at the
point that we'll likely hit platform limits, avoiding unnecessary HTTP
calls and as noted in #45482, hitting Node out-of-memory errors.
We need to make sure that we `push` instead of `unshift` to return the
results array in newest-first.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As part of follow-up changes, we'll be making changes to the changelog
functionality.
To determine more meaningful insight into whether this has succeeded, we
can add instrumentation to determine how many HTTP calls are being made.
feat(lint): add `types-location` rule and enable it for `lib/modules`
Reviewers consistently ask for exported types to be moved into a
colocated `types.ts`. Add a `renovate/types-location` oxlint rule that
reports `export interface` / `export type` declarations outside such a
file, and turn it on across `lib/modules`.
Re-exports (`export type { X }`, `export type *`), file-local types, and
values (enums, classes, functions) are left alone. `schema.ts` files and
`schema/` directories are excluded via config, matching how
`zod-schema-location` is configured — inferred types belong next to the
schema they are derived from.
Relocating the 87 existing violations means:
- new `types.ts` files for the modules that had none
- `terragrunt/common.ts` folded into its `types.ts`, as it held nothing
else
- `RangeBound` in `versioning/gradle/compare.ts` un-exported, since only
a file-local interface referenced it
- `bazel-module/parser/fragments.ts` split from its inferred types, which
now live in `parser/types.ts` and infer through a namespace import so
each schema keeps its merged name
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.
mithil