* 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
Renovate uses the Debian datasource to update packages from Debian repositories.
The debian datasource is meant for projects that:
- depend on Debian-based systems, or
- depend on Debian-based distributions, like Ubuntu
The dockerfile manager detects packages installed by apt install or apt-get install in a RUN instruction.
Anywhere else, you must combine the Debian datasource with regex managers for Renovate to detect your dependencies.
Set URL when using a Debian repository
To use a Debian repository with the datasource, you must set a properly formatted URL with specific query parameters as registryUrl:
components: Comma-separated list of repository components (e.g.,main,contrib,non-free).binaryArch: Architecture of the binary packages (e.g.,amd64,all).suite:- A rolling release alias like
stable. - A fixed release name such as
bullseyeorbuster.
- A rolling release alias like
!!! note
These parameters are used to give Renovate context and are not directly used to call the repository.
Therefore, the registryUrl has not to be a valid URL for a repository.
Example:
https://deb.debian.org/debian?suite=stable&components=main,contrib,non-free&binaryArch=amd64
This URL points to the stable suite of the Debian repository for amd64 architecture, including main, contrib, and non-free components.
Dockerfile support
When using Debian-based images, it is common to use a version pin for your packages, like so:
FROM debian:trixie
RUN apt-get update \
&& apt-get install -y --no-install-recommends curl=8.14.1-2 \
&& rm -rf /var/lib/apt/lists/*
This provides reproducibility in the case that the upstream package updates under you.
The dockerfile manager extracts these packages, allowing updates to them directly, without needing a Custom Manager.
The dockerfile manager does not work out a registryUrl from your base image, so it skips these packages with skipReason: unknown-registry rather than look them up against a suite which may hold versions your image cannot install.
Set the registryUrls which match your base image with a packageRules entry to have them looked up.
{
"packageRules": [
{
"matchFileNames": ["Dockerfile"],
"matchDatasources": ["deb"],
"registryUrls": [
"https://deb.debian.org/debian?suite=trixie&components=main,contrib,non-free&binaryArch=amd64"
]
}
]
}
Usage Example
Where the version is not given to apt directly - say it is held in an environment variable - you can extract it with a custom manager.
First you would set a custom manager in your renovate.json file for Dockerfile:
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"customManagers": [
{
"customType": "regex",
"managerFilePatterns": ["/^Dockerfile$/"],
"matchStrings": [
"#\\s*renovate:\\s*?(suite=(?<suite>.*?))?\\s*depName=(?<depName>.*?)?\\sENV .*?_VERSION=\"(?<currentValue>.*)\""
],
"registryUrlTemplate": "https://deb.debian.org/debian?suite={{#if suite }}{{suite}}{{else}}stable{{/if}}&components=main,contrib,non-free&binaryArch=amd64",
"datasourceTemplate": "deb"
}
]
}
Then you would put comments in your Dockerfile, to tell Renovate where to find the updates:
FROM debian:bullseye
# renovate: suite=bullseye depName=gcc-11
ENV GCC_VERSION="11.2.0-19"
RUN apt-get update && \
apt-get install -y \
gcc-11="${GCC_VERSION}" && \
apt-get clean
When the apt package for gcc is updated, Renovate updates the environment variable.
{
"packageRules": [
{
"matchDatasources": ["deb"],
"matchPackageNames": ["gcc-11"],
"registryUrls": [
"https://deb.debian.org/debian?suite=stable&components=main,contrib,non-free&binaryArch=amd64"
]
}
]
}
Artifactory
The Debian datasource can be used with Artifactory.
Supported repository types
The debian datasource supports these repository types:
- virtual
- local
- remote
Set a registryUrl
To use Artifactory, first configure the deb datasource by setting the registryUrl.
https://<host>:<port>/artifactory/<repository-slug>?suite=<suite>&components=<components>&binaryArch=<binaryArch>
https://artifactory.example.com:443/artifactory/debian?suite=bookworm&components=main,contrib,non-free&binaryArch=amd64
Authenticating to Artifactory
If Artifactory asks for authentication, you must set up a host rule. First, generate a password for Renovate with Artifactory's "Set Me Up" feature. Then, add the following configuration:
{
"hostRules": [
{
"hostType": "deb",
"matchHost": "https://artifactory.example.com:443/artifactory/debian",
"username": "myuser",
"password": "< the generated password >"
}
]
}