Support refreshing Gradle lockfiles from private repositories

[biniona]

Tell us more.

Problem

It appears that hostRules credentials are not forwarded to the Gradle subprocess for lockfile refreshes, meaning Gradle is unable to refresh lockfiles that contain packages from private repositories. The Mend-specific customEnvVariables feature can pass env vars to subprocesses, but it's not available on hosted Mend Renovate instances, and even where available it requires users to add System.getenv() placeholders in their build files to consume the variables.

When a Gradle project resolves dependencies or plugins from a private Maven repository (e.g., Artifactory), lockfile updates via ./gradlew ... --write-locks fail with 401 Unauthorized. This happens even when hostRules are correctly configured with hostType: 'maven'.

Example config (working for version lookups, failing for lockfile updates):

{
  hostRules: [
    {
      matchHost: 'https://my_private_repo.com/artifactory/my-maven/',
      hostType: 'maven',
      username: '{{ secrets.ARTIFACTORY_USER }}',
      password: '{{ secrets.ARTIFACTORY_TOKEN }}',
    },
  ],
}

Root cause

After investigating this alongside Claude, I believe the following is the issue:

hostRules credentials are used by Renovate's own HTTP layer (the Maven datasource) for version lookups, but do not appear to be passed to the ./gradlew subprocess that regenerates lockfiles. I was unable to find hostRules integration in the Gradle manager's artifacts.ts.

This is a known pattern documented in docs/usage/getting-started/private-packages.md:

"Because of this need to convert hostRules credentials into a format which package managers understand, sometimes artifact updating can fail due to missing credentials. Sometimes this can be resolved by changing Renovate configuration, but other times it may be due to a feature gap."

That page lists credential injection support for bundler, composer, gomod, helm, npm, maven (pom.xml), nuget, pip, pipenv, pip-compile, and poetry. Gradle is absent from this list.

The docs/usage/java.md section states "The manager for Gradle makes use of the maven datasource" and shows how to configure hostRules — but this only covers Renovate's own dependency lookups, not the Gradle subprocess. As a user, this was a bit surprising as I expected these guidelines to also apply for lockfile updates.

Proposed solution: Generate a temporary init.renovate.gradle script

After discussing this with Claude for a while, here is the solution we arrived at. After local testing and some searching this seems promising, but definitely open to other approaches.

Gradle supports --init-script <path>, which runs a Groovy script before evaluating the build. The Gradle manager could generate a temporary init.renovate.gradle that applies credentials from matching hostRules to all MavenArtifactRepository instances — both in pluginManagement (settings) and allprojects (dependencies). Each hostRule with hostType: 'maven' and credentials would produce its own startsWith check, so multiple private registries are supported in a single init script.

Example generated init.renovate.gradle (for a single hostRule):

// Runs before settings.gradle is evaluated — required because
// pluginManagement repositories resolve during settings evaluation,
// so settingsEvaluated would be too late.
beforeSettings { settings ->
    // Covers plugins applied via the modern plugins { } DSL block.
    // These are declared in settings.gradle's pluginManagement section.
    settings.pluginManagement {
        repositories {
            all { repo ->
                if (repo instanceof MavenArtifactRepository) {
                    // Match by URL prefix, derived from hostRules.matchHost
                    if (repo.url.toString().startsWith('https://my_private_repo.com/artifactory/my-maven/')) {
                        repo.credentials {
                            username = 'renovate-provided-username'
                            password = 'renovate-provided-token'
                        }
                    }
                }
            }
        }
    }
}

allprojects {
    // Covers the buildscript classpath — dependencies needed by the build
    // itself (e.g., classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:...'
    // in a buildscript { } block). Separate from pluginManagement above.
    buildscript {
        repositories {
            all { repo ->
                if (repo instanceof MavenArtifactRepository) {
                    if (repo.url.toString().startsWith('https://my_private_repo.com/artifactory/my-maven/')) {
                        repo.credentials {
                            username = 'renovate-provided-username'
                            password = 'renovate-provided-token'
                        }
                    }
                }
            }
        }
    }
    // Covers regular library dependencies (implementation, api, etc.)
    // across all subprojects.
    repositories {
        all { repo ->
            if (repo instanceof MavenArtifactRepository) {
                if (repo.url.toString().startsWith('https://my_private_repo.com/artifactory/my-maven/')) {
                    repo.credentials {
                        username = 'renovate-provided-username'
                        password = 'renovate-provided-token'
                    }
                }
            }
        }
    }
}

Note: Credentials use single-quoted Groovy strings (not double-quoted) to prevent GString interpolation — a password containing $ in a double-quoted string would be interpreted as a variable reference or expression, potentially breaking the build or executing arbitrary code. Single-quoted strings only require escaping \ and '.

Why this approach:

• Works regardless of how the user's build files handle credentials — no need for System.getenv() placeholders, Gradle properties, or any specific pattern in settings.gradle/build.gradle
• Users don't need to change their build files
• Handles both plugin repositories and dependency repositories
• Uses a native Gradle mechanism (--init-script)
• The file is temporary (never committed) and scoped to the Renovate execution

Precedent in the codebase: npm credential file writing

The closest precedent is the npm manager, which uses the same "write temporary credential file → run subprocess → clean up" pattern we're proposing for Gradle:

1. processHostRules() calls hostRules.findAll({ hostType: 'npm' }) and translates each rule into .npmrc format (e.g., //registry.company.com/:_authToken=token123)
2. updateNpmrcContent() saves the original .npmrc, then writes the credential-augmented version to disk
3. The npm/yarn/pnpm subprocess runs and reads credentials from .npmrc
4. resetNpmrcContent() restores the original .npmrc or deletes it if it didn't exist before

This save → write → run → restore cycle is repeated for npm, yarn, and pnpm in the npm orchestrator.

The Gradle implementation would follow the same structure but simpler: since init.renovate.gradle is always a new file (never pre-existing), there's no save/restore — just write and delete.

Security considerations

• Equivalent risk to existing managers — same pattern as pip-compile, npm, and composer. Credentials already trusted to Renovate are translated into a format the package manager can consume.
• Credentials on disk — the init.renovate.gradle file is temporary, never committed, and scoped by matchHost. Comparable to how npm writes tokens to .npmrc. The file is explicitly deleted after the ./gradlew command completes (success or failure) using a try/finally pattern, mirroring how the npm manager always calls resetNpmrcContent() after execution.
• Override behavior — the init script overwrites any credentials already set on matching repositories during the Renovate run. This is intentional: during a Renovate run, Renovate's credentials should be authoritative. The init.renovate.gradle file doesn't exist in CI, local dev, or any other context.
• Log exposure — mitigated by the existing -q (quiet) flag on the ./gradlew command.

Gradle version requirement

The beforeSettings init script hook requires Gradle 6.0+ (released November 2019). Tested this with Claude across Gradle 5.6.4 (fails), 6.0.1, 7.4.1, and 8.13 (all pass). The implementation must include a version guard: if the Gradle version (from gradle-wrapper.properties) is < 6.0, credential injection is skipped with a warning — the lockfile update still proceeds, it just won't have private registry credentials.

PR

I'd be happy to submit a PR for this!

[Churro]

How do you currently provide the credentials when updating your lock files locally?

[biniona]

We currently use environment variables to specify Maven repository credentials when using Gradle (example of this can be found in this Stack Overflow post answer). This is also how the Renovate user in the original Gradle lockfile issue seemed to specify their credentials (this seems to require a self hosted Mend Renovate instance however).

In looking around online to see how others specify credentials, the main other way seems to be gradle.properties files.

I think as an organization we would be happy to use the environment variable approach or the gradle.properties approach if it worked through a hosted Renovate instance. The downside of those approaches is that they require that Renovate users modify their build.gradle files to match what Renovate supplies (either properties with specific names or env vars with specific names). The init.gradle approach seems like a better user experience in that it should allow users to keep using their current credential specification style while still being able to use Renovate.

Extra Context: I just ran another series of local tests with Claude to confirm the override behavior. The init script hard-codes credentials (mirroring what Renovate would generate), and all tests used --refresh-dependencies to eliminate Gradle caching. The findings support that an init script overrides other credential specification strategies:

Test	Credential method in build files	Build file creds	Init script	Expected	Result
A	gradle.properties	wrong	none	FAIL	FAIL (401)
B	gradle.properties	wrong	correct creds	SUCCESS	SUCCESS
C	gradle.properties	correct	wrong creds	FAIL	FAIL (401)
D	System.getenv()	wrong	none	FAIL	FAIL (401)
E	System.getenv()	wrong	correct creds	SUCCESS	SUCCESS
F	System.getenv()	correct	wrong creds	FAIL	FAIL (401)

[biniona]

Hi — wanted to follow up on this and keep the conversation going.

Unless there are concerns or an alternative direction the team would prefer, I'm planning to put together a PR implementing this. The approach would follow the same pattern as the npm manager's credential file writing (processHostRules → write temp file → run subprocess → clean up), adapted for Gradle's --init-script mechanism.

I'm also considering filing this as a bug report, since Renovate documents support for both Gradle lockfile maintenance and private Maven registry authentication as separate features, but they fail unexpectedly when used together. Happy to keep it as a discussion-only if the team sees it as a feature gap rather than a bug.

Happy to discuss any design considerations before I start — particularly around whether the team would prefer a different credential injection strategy (e.g., gradle.properties vs init.gradle).

[rmiller-lendable]

I'm running into this issue currently. Was a workaround found or any progress made with a fix?