Gradle Dependency Verification fails on Bitrise - what should I do? (BitriseMirrorApacheCentral)

How To
1

The error

If your Android build on Bitrise started failing with a Gradle dependency verification error, look for these signals in the Install missing Android SDK components step (or in Activate Gradle Mirrors / Gradle Runner, whichever runs first in your workflow):

Dependency verification failed for configuration ...

This can indicate that a dependency has been compromised. Please carefully verify the checksums.

and at least one failed artifact reported as coming from the Bitrise Maven Central mirror, e.g.:

from repository BitriseMirrorApacheCentral

All three together are what tell you this Q&A applies. The “Dependency verification failed for configuration” and “compromised … verify the checksums” messages are generic to any Gradle dependency verification failure (a real checksum mismatch can happen for other reasons too). It’s the BitriseMirrorApacheCentral repository name that confirms the failure is the mirror-specific case described here.

The full block looks like this:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project '<your-project>'.
> Dependency verification failed for configuration 'classpath'
N artifacts failed verification:
  - <artifact>.jar (<group>:<name>:<version>) from repository MavenRepo
  - <artifact>.pom (<group>:<name>:<version>) from repository BitriseMirrorApacheCentral
This can indicate that a dependency has been compromised. Please carefully verify the checksums.
Open this report for more details: file:///bitrise/src/build/reports/dependency-verification/at-<id>/dependency-verification-report.html

The exact artifacts will differ between projects. They may be the artifacts the mirror serves directly, or plugins / transitive dependencies of plugins injected by the mirror-activating step.

Why this happens

Bitrise’s Maven Central mirror is now activated by default for all Android builds on Bitrise. The mirror is auto-enabled in the build VM at boot, so it’s active even if your workflow doesn’t include any of the steps below. Additionally, if your workflow runs any of these steps (Install missing Android SDK components, Activate Gradle Mirrors, or Gradle Runner), the first one to run also writes an init file under $HOME/.gradle/init.d/ that points Gradle at the Bitrise mirror.

Customers using the Bitrise Build Cache Add-On for Gradle additionally get $HOME/.gradle/init.d/bitrise-build-cache.init.gradle.kts, which registers the Bitrise Build Cache and Bitrise Gradle Analytics Gradle plugins.

These init scripts conflict with Gradle’s Dependency Verification feature, which requires every plugin (and every transitive dependency of those plugins) to be listed in $PROJECT_ROOT/gradle/verification-metadata.xml. When verification is enabled and an entry is missing (or its checksum doesn’t match the one the mirror serves), Gradle exits with the error above.

Because the mirror is now active for all Android builds, any project using Gradle Dependency Verification can hit this, not only Bitrise Build Cache customers.

What to do

The fix is to list the required plugins (and their dependencies) in your verification-metadata.xml, and pin the version of whichever step activates the Maven Central mirror in your workflow.

Step by step

1. Identify which step activates the Maven Central mirror in your workflow. It’s the first one of these to run: Install missing Android SDK components, Activate Gradle Mirrors, or Gradle Runner.

Note: If your workflow runs multiple steps that bundle the Bitrise Build Cache CLI (for example, Activate Bitrise Build Cache for Gradle together with Activate Gradle Mirrors), pin every one of them to a patch version that ships the same CLI version.

The plugin checksums in verification-metadata.xml are tied to the CLI that wrote them. If two co-located steps disagree on plugin versions, the build fails dependency verification.

Steps that bundle the CLI:

  • activate-build-cache-for-gradle
  • activate-react-native-features
  • activate-gradle-features
  • install-missing-android-tools
  • activate-gradle-mirrors
  • gradle-runner

Use the dependency matrix at https://bitrise-io.github.io/bitrise-build-cache-cli/dependency-matrix to look up the CLI version each step ships.

2. Lock the activating step’s version to the latest patch (here 0.1.2 is just an example, use the latest patch). This currently has to be done in bitrise.yml:

Note: You will need to update your verification-metadata.xml each time you update the step’s version.

- activate-gradle-mirrors@0.1.2:
    inputs:
    - verbose: 'true'

3. Find the CLI version used by the activating step in your build log. The step prints the CLI version it ran with near the start of its log section. If you can’t find it, use the latest CLI release: https://github.com/bitrise-io/bitrise-build-cache-cli/releases/latest. Open the corresponding release page (https://github.com/bitrise-io/bitrise-build-cache-cli/releases/tag/<VERSION>) and download the attached verification-metadata.xml.

Note: If the Bitrise Maven Central mirror is active in your workflow (the default for all Android builds on Bitrise), download verification-metadata-mirror.xml instead. Its SHA-256 checksums match what the mirror serves, while the plain verification-metadata.xml records origin Maven Central checksums and will fail verification when the mirror is active. The mirror reference asset is available starting with CLI v2.4.6.

4. Add the components content from the downloaded metadata into your $PROJECT_ROOT/gradle/verification-metadata.xml.

5. Review and commit the changes.

Note: the reference metadata is collected using a simple Gradle project and a specific platform runtime version. You might find that in your setup Gradle pulls slightly different dependencies. In that case you’ll need to regenerate the metadata yourself (see below).

Updating the verification metadata yourself

Do this every time you bump the activating step, or if the reference metadata still differs from what Gradle expects in your environment.

The Bitrise Build Cache CLI (https://github.com/bitrise-io/bitrise-build-cache-cli) has a command that injects the plugin dependencies in a way that is meant for collecting metadata, not for production.

  1. Update every step in your workflow that bundles the Bitrise Build Cache CLI (Activate Bitrise Build Cache Add-On for Gradle, Activate Gradle Mirrors, Install missing Android SDK components, Activate React Native Features, Gradle Runner, etc.) to patch versions that all ship the same CLI version, locking each one to an exact patch in bitrise.yml. Use the dependency matrix at https://bitrise-io.github.io/bitrise-build-cache-cli/dependency-matrix to find matching versions.

  2. On your development machine (or on Bitrise in a separate workflow), install the CLI version listed by the dependency matrix:

    # Replace CLIVERSION with the CLI version you want to install,
# e.g. v2.4.6. Use the dependency matrix to pick the right version
# for your step versions:
#   https://bitrise-io.github.io/bitrise-build-cache-cli/dependency-matrix

curl --retry 5 -sSfL 'https://raw.githubusercontent.com/bitrise-io/bitrise-build-cache-cli/main/install/installer.sh' | sh -s -- -b /tmp/bin -d "CLIVERSION"

  3. If you already have the Bitrise Build Cache enabled, back up $HOME/.gradle/init.d/bitrise-build-cache.init.gradle.kts. The next step will overwrite it.

  4. If your production workflow has the Bitrise Maven Central mirror active (the default for all Android builds on Bitrise), activate the mirror locally now so the regenerated metadata records mirror-served checksums instead of origin ones:

    BITRISE_MAVENCENTRAL_PROXY_ENABLED=true /tmp/bin/bitrise-build-cache activate gradle-mirrors -d

  5. Run the CLI’s gradle-verification add-reference-deps command:

    # This overwrites the existing cache config in
# $HOME/.gradle/init.d/bitrise-build-cache.init.gradle.kts!

/tmp/bin/bitrise-build-cache gradle-verification add-reference-deps

    This generates an init script with the latest plugins in dry-run mode.

  6. In your project folder, run your usual workflow to write the verification metadata, e.g.:

    ./gradlew tasks --write-verification-metadata sha256

  7. Review the metadata diff, commit, and migrate the changes to your production workflow.

  8. If you backed up $HOME/.gradle/init.d/bitrise-build-cache.init.gradle.kts locally, you can revert that backup now.

This way you can keep your dependencies locked while staying on the latest Bitrise Build Cache CLI.

New Gradle Mirrors on Bitrise to Help Avoid Maven Central Rate Limits (429 - Too Many Requests)