Gregor Zeitlinger
0d9888a4f2
* feat(datasource): add GraalVM version datasource with support for JDK and JRE releases * feat(datasource): add GraalVM version datasource with support for JDK and JRE releases * feat(datasource): add GraalVM version datasource with support for JDK and JRE releases * feat(datasource): add GraalVM version datasource with support for JDK and JRE releases * feat(datasource): add GraalVM version datasource with support for JDK and JRE releases * add coverage * fix * fix * fix * code cov * code cov * code cov * refactor(datasource): integrate GraalVM into java-version datasource Merges graalvm-version datasource into java-version as a unified multi-vendor Java distribution datasource. Implements vendor-based modular architecture with routing layer for Adoptium (Eclipse Temurin) and Oracle GraalVM. Architecture: - Vendor-specific handlers (adoptium.ts, graalvm.ts) with routing in index.ts - Vendor-aware system detection with different arch/os mappings per vendor - Custom registry support for GraalVM's mise-java API - Adoptium remains the default registry for backwards compatibility Package names: - New explicit: adoptium-jdk, adoptium-jre, oracle-graalvm-jdk, oracle-graalvm-jre - Legacy (map to Adoptium): java, java-jdk, java-jre Changes: - Created adoptium.ts and graalvm.ts vendor handlers - Enhanced common.ts with vendor detection and vendor-specific system mappings - Updated index.ts with routing layer and custom registry support - Merged test suites with comprehensive coverage for both vendors - Updated mise manager integration to use JavaVersionDatasource - Removed graalvm-version datasource directory All 65 datasource tests and 93 mise manager tests passing. * fix * test(datasource): add coverage for non-HttpError paths in java-version * fix(datasource): remove dead code and add coverage for java-version Remove unreachable HttpError handling from _getReleases catch block since both getAdoptiumReleases and getGraalvmReleases handle HttpError internally. Add test for the graalvmRegistryUrl fallback when registryUrl is undefined. * fix(datasource): address review comments for GraalVM datasource - Remove unused 'datasource-graalvm-version' cache namespace - Convert MiseJavaRelease interface to Zod schema and derive type from it - Use http.getJson() with the Zod schema in getGraalvmReleases instead of getJsonUnchecked, letting the schema handle invalid/empty responses - Update getGraalvmReleases test mock to use getJson * docs: remove unused datasource-graalvm-version from cacheTtlOverride docs * fix(datasource): preserve Adoptium config typing * fix(datasource): harden GraalVM release parsing * fix(datasource): address GraalVM review feedback * test: cover GraalVM mise package mapping * test(datasource): cover default GraalVM registry fallback * test(datasource): cover legacy registry resolution * test(datasource): type legacy datasource mocks * fix(datasource): harden GraalVM defaults and responses * refactor(datasource): use function-only registry accessors * test(datasource): cover registry accessor functions * test: restore coverage exclusions * chore: retrigger CI checks
With Repology you can look up package versions from many package repositories. You can combine Repology with regex managers to update dependencies which are not supported by Renovate.
The packageName field should be constructed using the repository identifier and the actual package name separated by a slash.
For example: alpine_3_12/gcc would look for a binary (or source package) called gcc within the alpine_3_12 repository.
A list of all supported repositories can be found on the Repology homepage.
To find the correct identifier, select the repository you want and copy the identifier in the URL: https://repology.org/repository/<identifier>.
For example, the Alpine Linux 3.12 repository has this URL: https://repology.org/repository/alpine_3_12 and has this repository identifier: alpine_3_12.
Usage Example
Say you're using system packages in a Dockerfile and want to update them with Repology. With the Repology datasource you can "pin" each dependency, and get automatic updates.
First you would set a custom manager in your renovate.json file for Dockerfile:
{
"customManagers": [
{
"customType": "regex",
"managerFilePatterns": ["/^Dockerfile$/"],
"matchStrings": [
"#\\s*renovate:\\s*datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?\\sENV .*?_VERSION=\"(?<currentValue>.*)\"\\s"
],
"versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}"
}
]
}
Then you would put comments in your Dockerfile, to tell Renovate where to find the updates:
FROM alpine:3.12.0@sha256:a15790640a6690aa1730c38cf0a440e2aa44aaca9b0e8931a9f2b0d7cc90fd65
# renovate: datasource=repology depName=alpine_3_12/gcc versioning=loose
ENV GCC_VERSION="9.3.0-r2"
# renovate: datasource=repology depName=alpine_3_12/musl-dev versioning=loose
ENV MUSL_DEV_VERSION="1.1.24-r8"
RUN apk add --no-cache \
gcc="${GCC_VERSION}" \
musl-dev="${MUSL_DEV_VERSION}"
When the operating system package for gcc of Alpine Linux 3.12 is updated, Renovate updates the environment variable.
!!! tip
We recommend you try loose or deb versioning for distribution packages first.
This is because the version number usually doesn't match Renovate's default semver-coerced specification.