skip to content

Wrapper validation fails in CI on an existing project. How do you investigate and respond?

level: seniorimportance: should knowfreq 32%

answer

  1. security gate, not flaky test
  2. which jar + computed hash from output
  3. git log --follow the jar
  4. regenerate with trusted gradle, diff hash
  5. tampering -> rotate exposed secrets

basics

~20 s

Treat it as a potential supply-chain incident, not a flaky test. Identify which jar failed, check git history for who changed it, and compare against a freshly regenerated official jar. Don't run the build until resolved.

solid answer

~50 s

Treat a validation failure as a possible compromise, not a nuisance to silence. First, read the action output to see **which** `gradle-wrapper.jar` failed and its computed SHA-256. Inspect `git log -- gradle/wrapper/gradle-wrapper.jar` to find when and by whom it changed, and review that commit/PR. Reproduce by regenerating the official jar in a clean clone: run `./gradlew wrapper --gradle-version <x>` from a trusted Gradle install, then diff the byte/hash against the repo's jar. If the repo jar's hash now matches a published checksum, the original was tampered; commit the regenerated genuine jar. If a recent **legitimate** Gradle upgrade produced a jar the action doesn't yet recognize, update the validation action to a newer version that knows the latest checksums. Until you've confirmed it's a benign cause, **do not** disable the check or run the build with secrets — that's exactly the scenario validation exists to stop. If tampering is confirmed, rotate any secrets that earlier CI runs exposed.

code

bash · 6 lines
bash
# Trace and independently regenerate, then compare
git log --follow -- gradle/wrapper/gradle-wrapper.jar

# Use a TRUSTED local gradle, not ./gradlew, to regenerate:
gradle wrapper --gradle-version 8.7
sha256sum gradle/wrapper/gradle-wrapper.jar   # compare to the failing jar's hash

go deeper

for a junior

Know not to ignore or disable the failure; flag it and find which jar changed.

for a middle

Trace the jar's git history and distinguish a legitimate upgrade (update the action) from corruption (regenerate).

for a senior

Run an independent regeneration with a trusted Gradle, never trust the suspect ./gradlew, and treat confirmed tampering as an incident with secret rotation.

for a principal

Drive incident response: scope exposed credentials across runs, audit blast radius, and harden policy so the gate can't be bypassed in future.

## Mindset: it's a security gate firing A wrapper-validation failure means *the bootstrapper jar in the repo is not a recognized official Gradle wrapper jar.* The two innocent explanations are (a) a brand-new Gradle version the validator doesn't yet recognize, or (b) corruption; the dangerous one is (c) deliberate tampering. You investigate to tell them apart — you do not start by disabling the check. ## Step 1 — read the failure The action reports each failing path and its computed SHA-256. Note **which** jar (a monorepo may have several) and the hash. ## Step 2 — trace provenance ```bash git log --follow -- gradle/wrapper/gradle-wrapper.jar ``` Who last changed it, in which commit/PR, and was that change a legitimate wrapper upgrade or an unrelated/unexplained edit? An unexplained binary change in a PR that wasn't about Gradle upgrades is a red flag. ## Step 3 — regenerate from a trusted source and compare From a clean checkout, using a trusted local Gradle, regenerate the wrapper: ```bash gradle wrapper --gradle-version 8.7 # trusted Gradle binary, not ./gradlew sha256sum gradle/wrapper/gradle-wrapper.jar ``` Compare the regenerated jar's hash to the repo's failing jar: - **They differ** and the regenerated one is official -> the repo jar was altered (tampering/corruption). Replace it with the regenerated genuine jar. - **They match a published checksum but the action still failed** -> likely an outdated validator that doesn't know the newest release; upgrade the action. Using `gradle` (a trusted install) rather than the repo's possibly-compromised `./gradlew` is important — don't ask the suspect to vouch for itself. ## Step 4 — respond to the cause - **Legitimate new version, stale validator:** bump `gradle/actions/wrapper-validation` to a version that recognizes the new checksum; re-run. - **Corruption (e.g. bad merge of a binary):** re-checkout/regenerate the official jar and commit it. - **Confirmed tampering:** this is an incident. Identify the introducing commit, assume earlier CI runs may have executed malicious code, and **rotate secrets/tokens** those runs had access to. Audit what those runs did. Then restore the genuine jar. ## What never to do - Don't delete or `continue-on-error` the validation job to get green. - Don't run the build with production secrets while the jar is unverified. - Don't blindly `git checkout` the jar from the suspect branch — verify against an independent regeneration.

  • Why regenerate with `gradle` rather than the repo's `./gradlew`?
    Because ./gradlew runs the very jar under suspicion. If it's compromised, asking it to regenerate or validate itself is meaningless — you need an independent, trusted Gradle install.
  • Validation fails right after a legitimate Gradle upgrade. What's the likely fix?
    The validator action is probably older than the new Gradle release and doesn't know its checksum yet. Upgrade the action to a version that recognizes the latest published checksums, then re-run.
  • If you confirm the jar was tampered with, what beyond replacing it must you do?
    Treat earlier CI runs as potentially compromised: rotate any secrets/tokens those runs could access, audit their actions, and identify the introducing commit/author.

saying these in an interview costs you the question

  • Disabling or marking the validation job continue-on-error to make CI green.
  • Assuming it's just a flaky/transient failure and re-running until it passes.
  • Restoring the jar from the same suspect branch without independent verification.

context

resolving links…