Fix #6309: Throw actionable exception on zero or negative version code

[thirumani-vihaan]

Explanation
Fixes #6309

This prevents shallow Git clone math from silently breaking the build pipeline.

When a user clones with --depth, countCommits returns a small number (e.g., 10). Subtracting the starting commit number (2289) results in a heavily negative value, which Android OS rejects.

This PR adds a check(versionCode > 0) state validation that catches this specific scenario and throws an IllegalStateException instructing the user to run git fetch --unshallow before proceeding. A regression test simulating a 10-commit shallow clone has been added to verify this behavior.

Essential Checklist

• The PR title starts with "Fix #bugnum: "
• The explanation section above starts with "Fixes #bugnum: "
• Any changes to scripts/assets files have their rationale included in the PR explanation.
• The PR follows the style guide.
• The PR is made from a branch that's not called "develop" and is up-to-date with "develop".
• The PR does not contain any unnecessary code changes from Android Studio.
• The PR is assigned to the appropriate reviewers.

[coderabbitai]

Caution

Review failed

An error occurred during the review process. Please try again later.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Neer-rn]

LGTM! Please remove the last part of the PR description. You can simply link the closed PR instead. Thank you for the work. @adhiamboperes PTAL

[oppiabot]

Unassigning @Neer-rn since they have already approved the PR.

[oppiabot]

Assigning @manas-yu for code owner reviews. Thanks!

[github-actions]

Coverage Report

Results

Number of files assessed: 1
Overall Coverage: 99.21%
Coverage Analysis: PASS ✅

Passing coverage

Files with passing code coverage

File	Coverage	Lines Hit	Status	Min Required
TransformAndroidManifest.kt scripts/src/java/org/oppia/android/scripts/build/TransformAndroidManifest.kt	99.21%	125 / 126	✅	70%

To learn more, visit the Oppia Android Code Coverage wiki page

[adhiamboperes]

Thanks @thirumani-vihaan! I have left a comment inline, PTAL.

Please note that I have not yet reviewed the test file.

[adhiamboperes]

@thirumani-vihaan, this fix directly addresses the symptom described in the bug, but tt treats the symptom, not the cause. The check catches a negative version code, but it doesn't verify that the reason is a shallow clone. If the version code goes negative for some other reason (e.g. bad flavor offset config, integer overflow in rcVersionOffset, someone fmistakenly adjusting BASE_VERSION_CODE), running git fetch --unshallow won't fix a config bug.

Additionally, it doesn't handle the false-negative case. A shallow clone with enough depth, or an unlucky commit count, could still produce a small-but-positive version code that's incorrect, but it would sail through check(versionCode > 0) undetected.

A suggestion I have is to detect shallow clones explicitly e.g., via git rev-parse --is-shallow-repository or checking for .git/shallow and fail before even computing the version code, with a message that "you're in a shallow clone" rather than inferred from a downstream symptom.

Ideally, combine both approaches:

• Detect shallow clone explicitly wherever git history is queried and fail immediately with a precise message.
• Keep the check(versionCode > 0) as a defensive backstop for any cause of an invalid version code, but make its message generic ("computed version code is invalid, check versioning inputs") rather than assuming the shallow-clone cause, since that assumption won't always hold.