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()`.
* 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
Now we have instrumented our Git operations with tracing, we can make
sure that users who are not using OpenTelemetry still get insights into
their Git operation usage using a debug log output.
Following how other insights are produced, we can introduce a new type
in `lib/util/stats` for `GitOperationStats`, which will track the
overall execution for each operation type, and output them in the same
style as we use for other timing reports.
At the end of a Renovate run, we'll then make sure that this is logged
into a debug log for further investigation.
To create the report, we can make sure that we introduce a new
OpenTelemetry `SpanProcessor`, which will run when we end our Run, and
store any Git operations in `GitOperationStats`.
This adapts code from GPT-4.1 and code from [0].
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
[0]: https://github.com/yurisouza/monitoria-sdk/blob/ca9d751fa7c3a785a04f87b8966bb782b4617021/src/adapters/nestjs/span-duration-tracker.ts#L18-L27
Sebastian Poxhofer