Sebastian Poxhofer
97327c3d28
* 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()`.
Maven Central rate limiting and caching
Maven Central, hosted by Sonatype, receives a very large number of requests and has implemented rate limiting measures to manage organizational overconsumption. If you're experiencing 429 (rate limited) responses from Maven Central, you may need to optimize your caching strategy.
Renovate includes Maven caching optimizations, but they rely on having a persistent datasource cache. By default, Renovate uses a file-based cache, which means:
- Persistent environments (like self-hosted runners with persistent storage) will benefit from cross-run caching
- Ephemeral environments (like GitHub Actions or other CI/CD with fresh containers each run) won't benefit from caching across runs
To maximize caching effectiveness and reduce Maven Central requests:
- Use Redis for persistent caching: Configure a Redis instance for your Renovate datasource cache
- Ensure cache persistence: If using file-based caching, ensure the cache directory persists between Renovate runs
- Monitor rate limit warnings: Renovate will log warnings when receiving 429 responses from Maven Central
If you continue to experience rate limiting issues after implementing persistent caching, you may need to:
- Reduce the frequency of Renovate runs
- Consider using a Maven repository proxy with its own caching layer
!!! note
Dependencies that appear to be Gradle plugins (where the groupId or artifactId ends with .gradle.plugin) will not be looked up in Maven Central.
Making your changelogs fetchable
In case you are publishing artifacts and you want to ensure that your changelogs are fetchable by Renovate, you need to configure the scm section on their pom.xml file.
For example:
<scm>
<url>scm:git:https://github.com/path_to_repository</url>
</scm>
This is what allows Renovate to determine the sourceUrl, that it then uses to fetch the changelogs.
!!! note
This also works for private repositories.
It can leverage the same token that you had to configure in order to be able to reach the private Artifactory.
Specifying your project homepage
When opening a Pull Request Renovate uses the top level url property to determine the homepage of your project and shows it inside the Pull Request.
To customize you can set it inside your pom.xml.
For example:
<url>https://project.example.com</url>
latest and release tags
When latest or release values are present in a package's maven-metadata.xml, Renovate will map these to its tags concept.
This enables the use of Renovate's followTag feature.
However, Renovate will set respectLatest=false whenever the latest tag is found, because many Maven registries have been found to populate the tag unreliably.
You should use packageRules to set respectLatest=true if you wish to use this feature.