[Dependency Cache] Enable Dependency Cache on CI

[ParaskP7]

Project Thread: paaHJt-7CE-p2
Related: #13170 + #13122 + #13288
Depends On: a8c-ci-toolkit#135 -> a8c-ci-toolkit#138
Required By: buildkite-ci#576

---

Description

This PR enables dependency cache on CI for this project. 💾

The dependency cache mechanism is split between:

• A weekly scheduled save cache build (see commit and buildkite-ci#576 PR), which targets the below tasks only:
  • Mobile App (WooCommerce:assembleJalapenoDebug)
  • Wear App (WooCommerce-Wear:assembleJalapenoDebug)
  • Lint (WooCommerce:lintJalapenoDebug)
  • Unit Tests (ssembleJalapenoDebugUnitTest assembleDebugUnitTest)
  • Android Tests (assembleJalapenoDebugAndroidTest)
• A restore cache step that is run on targeted pipeline.yml related jobs, via their corresponding individual scripts:
  • Mobile App (prototype-build.sh)
  • Wear App (prototype-build.sh)
  • Lint (lint.sh)
  • Unit Tests (run-unit-tests.sh)
  • Android tests (run-instrumented-tests.sh)

PS.1: The detekt job isn't targeted because it only takes about 20+ seconds of network request to download all the dependencies needed for this specific job (build + scan), which is about the same time it takes for the dependency cache to actually be restored, which is more or less about 10+ seconds (build). Thus, this optimization is not really worth it for this specific job. For all those other jobs targeted, it takes more than a minute of network requests to download all the dependencies needed (build + scan), and as such the diff is worth it.

PS.2: Dependency cache isn't enabled on the release-builds.yml pipeline just yet, but just temporarily, and until we become comfortable with running this new process on the main pipeline.yml pipeline.

---

Future Improvements

As per this comment, me and @wzieba has been discussing on DMs about some possible future improvement, which are including but are not limited to the below list:

1. Only execute the assemble android test task, which depends on assemble task anyway, and would most likely resolve most of the dependencies, for all other tasks to benefit from. However, this needs further testing to make sure that running other tasks such us lint and assemble unit test are providing little to no help.
2. Create a custom Gradle task and utilize Gradle's init scripts (init.d). Using the init script, go through all available modules for a project, and then, using that custom Gradle task, resolve all dependencies for all tasks that are available per module. We could take some inspiration from plugins such as this.
3. Instead of scheduling the dependency cache build to run weekly (buildkite-ci#576), make it run more often, possibly scheduling it to even run daily. However, since dependencies are not being updated too often, and, even when they do on that specific week, it would only be for a few of them. This will indeed cause some extra network requests, but most of the dependencies cached would still benefit from the existing and weekly refreshed dependency cache.
4. Enable dependency cache on the release-builds.yml pipeline.

---

Testing information

This dependency cache solution was thoroughly tested via this #13170 test-only PR, but to help you asserting that this change is indeed making an impact, plus not causing any trouble for the project, try and follow the below:

• Save Cache:

  • Triggering schedules/dependency-cache.yml manually via this build:
    • Starts downloading the dependencies per task.
    • Caches the dependencies successfully.
      • Duration: 42s
      • Size: 625.74 MB
    • Total time it takes for the dependency cache job to complete: 7m 42s
  • Sending a Slack notification (#android-core-notifs):
    • On success, notifying that: The dependency cache has been updated. (p1736943241087289-slack-C0787KRDYDC)
    • On failure, notifying that: Failure to update the dependency cache. (not tested, but should behave similarly to ☝️)

• Restore Cache:

Job	BT (Without)	BT (With)	BT (Diff*)	NR (Without)	NR (With)	RC (Without)	RC (With)	Win
Mobile App	5m 38s	3m 53s	- 1m 45s	1m 15s	0s	0s	12s	1m 3s
Wear App	4m 43s	2m 56s	- 1m 47s	59s	0s	0s	15s	44s
Lint	6m 9s	4m 6s	- 2m 3s	1m 49s	0s	0s	14s	1m 35s
Unit Tests	6m 0s	3m 57s	- 2m 3s	1m 31s	0s (ish)	0s	10s	1m 21s
UI Tests	10m 3s	13m 37s	+ 3m 34s	1m 38s	0s	0s	15s	1m 23s

Note

• Without: Without Dependency Cache
• With: With Dependency Cache
• BT: Build Time
• NR: Network Requests
• RC: Restore Cache
• Win: NR (Without) - RC (With)

Warning

(*): The BT (Diff) presented above is relative, so don't read too much into it, it might not match with the WIN, which is a much more solid number. But still, it is nice to have and compare those two number together. To to be clear about that, although I tried to pick the most representative builds, without and with the dependency cache mechanism in place, there are other factors that can make any build faster, or slower for that matter (like build cache, firebase test lab, etc), so again, don't read too much into it.

---

Merge Instructions

• Wait for a8c-ci-toolkit#135 -> a8c-ci-toolkit#138 to be reviewed, approved and merged.
• Create a new a8c-ci-toolkit release (3.9.0 -> 3.9.1 ).
• Update CI_TOOLKIT to point to this newly created a8c-ci-toolkit release (3547e66 -> 6ac4eb4).
• Remove status: do not merge label.
• Merge this PR.
• Close [Dependency Cache] Enable Dependency Cache on CI [with GRADLE_RO_DEP_CACHE] #13122 and [Dependency Cache] Dependency Cache on CI per Project [without GRADLE_RO_DEP_CACHE] #13170 test-only PRs.

---

• I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on big (tablet) and small (phone) in case of UI changes, and no regressions are added.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce-Wear Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce-Wear Android
	Platform	⌚️ Wear OS
	Flavor	Jalapeno
	Build Type	Debug
	Commit	25a6483
	Direct Download	woocommerce-wear-prototype-build-pr13303-25a6483.apk

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Commit	25a6483
	Direct Download	woocommerce-prototype-build-pr13303-25a6483.apk