Skip to content

ci: make Gradle caching work by running the suite on main - #742

Open
jamesnrokt wants to merge 2 commits into
mainfrom
fix/ci-gradle-caching
Open

ci: make Gradle caching work by running the suite on main#742
jamesnrokt wants to merge 2 commits into
mainfrom
fix/ci-gradle-caching

Conversation

@jamesnrokt

@jamesnrokt jamesnrokt commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator

Background

No Gradle cache entry has ever existed for this repo — the cache listing holds only Trunk entries. Unit Tests reports 116 actionable tasks: 116 executed and re-downloads the Gradle distribution every run; the instrumented jobs log Gradle User Home cache not found. Will initialize empty.

The cause is structural, which is why just adding setup-gradle would have fixed nothing: setup-gradle is read-only off the default branch, and an entry written on a PR ref is visible only to that PR — but this workflow never ran on a push to main. No run was ever permitted to write the cache that PR jobs read.

What changed

  • Run this workflow on pushes to main, matching the other Rokt Android repos. Main runs may write, so the ordinary suite populates the cache — no bespoke warming job needed.
  • Gate the four jobs that require a PR context to pull_request only: trunk-check (check-mode: pull_request), pr-check-hadcoded-secrets, security-checks (diff-aware against a base branch) and automerge-dependabot (reads the PR number). kit-compatibility-test and pr-notify were already gated.
  • Add setup-gradle to the remaining Gradle jobs and replace the end-of-life gradle/gradle-build-action@v2.9.0 in instrumented-tests.yml. Pinned to the SHA the release workflows already use, so no new action version enters the supply chain.
  • org.gradle.caching=true — without it, a warm dependency cache still leaves 116 executed.
  • Pass --no-build-cache on every publish invocation in release-publish.yml and release-draft.yml, so released artifacts are always built from scratch and never assembled from cached task outputs.

cache-read-only: true is kept on build-kits.yml and instrumented-tests.yml, and only there. setup-gradle keys entries per job invocation, so build-kits' 22-kit matrix would otherwise write 22 entries per main commit and churn through the 10 GB repo limit.

Validation

Local populate pass, then clean and rebuild:

PASS A  2m 55s   42 actionable tasks: 40 executed, 2 from cache
PASS B  3s       42 actionable tasks: 12 executed, 23 from cache, 7 up-to-date

compileReleaseKotlin, compileReleaseJavaWithJavac and minifyReleaseWithR8 all FROM-CACHE, so outputs are correct as well as reused. actionlint and trunk check clean.

@jamesnrokt
jamesnrokt requested a review from a team as a code owner July 29, 2026 20:58
@cursor

cursor Bot commented Jul 29, 2026

Copy link
Copy Markdown

PR Summary

Low Risk
Changes are limited to CI configuration and Gradle caching flags; release builds are explicitly forced fresh with --no-build-cache.

Overview
CI now runs on pushes to main so Gradle dependency/build caches can be written on the default branch and reused by PR jobs (previously the workflow never ran on main, so caches could not populate).

Gradle setup is standardized across unit, lint, kit, instrumented, and build-kits jobs: gradle/actions/setup-gradle replaces the EOL gradle/gradle-build-action in instrumented tests; org.gradle.caching=true is enabled in gradle.properties. Matrix-heavy build-kits and instrumented workflows use cache-read-only: true to avoid cache churn from many writers.

PR-only jobs (trunk-check, security-checks, automerge-dependabot) are gated with if: github.event_name == 'pull_request'.

Release paths add --no-build-cache on all Maven publish/smoke steps in release-publish.yml and release-draft.yml so shipped artifacts are not assembled from cached task outputs.

Reviewed by Cursor Bugbot for commit d2896aa. Bugbot is set up for automated code reviews on this repo. Configure here.

No Gradle cache entry has ever existed for this repo. The unit-test job reported
"116 actionable tasks: 116 executed" and re-downloaded the Gradle distribution
every run; the instrumented jobs logged "Gradle User Home cache not found. Will
initialize empty." on every run.

The cause was structural. setup-gradle is read-only off the default branch and an
entry written on a PR ref is visible only to that PR, but this workflow only ran
on pull_request and workflow_dispatch — so no run was ever permitted to write the
cache that PR jobs need to read. Adding readers to a cache with no writer changes
nothing.

- Run this workflow on pushes to main, matching the other Rokt Android repos.
  Main runs are permitted to write, so the normal suite populates the cache.
- Gate the four jobs that require a pull request context to pull_request only:
  trunk-check (check-mode: pull_request), pr-check-hadcoded-secrets,
  security-checks (diff-aware against a base branch) and automerge-dependabot
  (reads the PR number). kit-compatibility-test and pr-notify were already gated.
- Add setup-gradle to the remaining Gradle jobs, and replace the end-of-life
  gradle/gradle-build-action@v2.9.0 in instrumented-tests.yml.
- Keep cache-read-only on build-kits.yml and instrumented-tests.yml. build-kits
  has an internal matrix over 22 kits and setup-gradle keys entries per job
  invocation, so leaving those writable would push one entry per kit per run.
- Enable org.gradle.caching so task outputs are reused, not just dependencies.
- Pass --no-build-cache on every publish invocation in release-publish.yml and
  release-draft.yml, so released artifacts are always built from scratch rather
  than assembled from cached task outputs.

Because the macOS lint jobs now also run on main, they write the macOS/arm64 key
their PR-side counterparts restore, so those jobs benefit too.

Verified locally that the build cache is correct and effective: a populate pass
took 2m55s ("40 executed, 2 from cache"), then a clean and rebuild took 3s
("12 executed, 23 from cache, 7 up-to-date") with compileReleaseKotlin,
compileReleaseJavaWithJavac and minifyReleaseWithR8 all FROM-CACHE.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jamesnrokt
jamesnrokt force-pushed the fix/ci-gradle-caching branch from b9ccf4e to 8db6e1a Compare July 29, 2026 21:00
@sonarqubecloud

Copy link
Copy Markdown

jamesnrokt added a commit that referenced this pull request Jul 30, 2026
…746)

* ci: remove hardcoded secrets check from PR workflow

Trunk already runs trufflehog at the PR level (trufflehog@3.90.6 in
.trunk/trunk.yaml), alongside a custom mparticle-api-key-check rule, so
this job was duplicating secret scanning that Trunk Check already covers.

The job was also intermittently red -- 3 failures in 70 recent runs, always
in ~5s. It failed on #742 while passing on #743 and #744 with identical
config. The cause is in the reusable workflow, which resolves and downloads
"latest" trufflehog at runtime by curling the GitHub releases API and
grepping the response; that step breaks when the API rate-limits. Trunk
pins its trufflehog version and has no runtime download, so it does not
share this failure mode.

Nothing in the workflow depends on the removed job; no other job referenced
it via needs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* ci: enable trufflehog-git to scan the commits a PR adds

The already-enabled trufflehog linter runs `trufflehog filesystem` against
changed files in the working tree, so it cannot see a secret that was
committed and then removed in a later commit on the same branch -- the file
no longer exists to scan.

trufflehog-git closes that gap. It runs `trufflehog git --since-commit
${upstream-ref}`, walking only the commits the PR adds, so it stays fast
(~1.7s) and does not resurface historical findings.

Demonstrated with a private key committed then removed on a branch:

  filesystem scan  -> missed it (only the pre-existing daily.yml FP)
  git-history scan -> PrivateKey <- probe-key.pem @ f48c6617

Both linters keep Trunk's default --only-verified, so this widens scan
scope, not the reporting threshold.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: James Newman <james.newman@rokt.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant