Gradle dependency cache on CI

[wzieba]

Description

This PR enables Gradle dependency cache.

Related toolkit PR: Automattic/a8c-ci-toolkit-buildkite-plugin#98

Testing instructions

Not needed

Images/gif

I re-run the same, :WooCommerce:dependencies task and results are as following:

Without cache	With cache

• 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.

[dangermattic]

	1 Message
📖	This PR is still a Draft: some checks will be skipped.

Generated by 🚫 Danger

[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
	Flavor	Jalapeno
	Build Type	Debug
	Commit	a02d970
	Direct Download	woocommerce-prototype-build-pr11621-a02d970.apk

[oguzkocer]

I re-run the same, :WooCommerce:dependencies task and results are as following:

May I ask where you ran this command? Did you ssh into the CI, if so, can you share details about the state of the CI at that time?

[oguzkocer]

Do we want to save the cache every run? There is some race condition related risks, but beyond that, (as far as I know) the Gradle cache is restored into a read-only cache. Whereas, the cache that's saved is from the regular dependencies folder that Gradle writes to. So, unless I am missing some weird interaction, the dependencies of the current task will always override the ones in remote. Since detekt and assemble require different sets of dependencies, that makes this an always partial cache, right?

[wzieba]

That's a good point! What do you think would be the best strategy? Should have a different cache key for each Buildkite job, or save dependency cache only for the job which requires most dependencies, in this case: probably "Instrumented tests"?

[oguzkocer]

I think we want to update the dependency cache as infrequently as we can, without over-complicating things. Not so much for addressing any issues - although I do think it'll help with race conditions - it's more so we can reason about how our dependency caching works. If it's updated everywhere, it'll be hard to track things down if anything goes wrong.

So, picking one task to save the dependencies makes sense to me. Instrumented tests also sound reasonable, but could you do a quick check using :dependencies task that this encapsulates everything we expect it to? I can't remember if implementation dependencies made available for this task or if it only downloads the androidImplementation ones.

An alternative approach might be to add a Gradle task to force download the dependencies. With that approach we'd be able to download the dependencies for all configurations. However, the last time I checked this was a bit tricky, so there is some initial development cost to it.

Besides that, I think we should only update it after every tag. That's one of the least frequent CI tasks and yet it's more than frequent enough to update the dependency cache. Any dependency added between two releases will need to be downloaded for every run, but that's not a problem at all in my opinion.

[wzieba]

May I ask where you ran this command? Did you ssh into the CI, if so, can you share details about the state of the CI at that time?

I modified pipeline: 7fa712b, I didn't ssh into the CI

[oguzkocer]

I re-run the same, :WooCommerce:dependencies task and results are as following:

As far as I know - and it's been a while since I looked into this - dependencies task will not download dependencies. It's also not a task that represents any of our use cases, except maybe dependency-tree-diff, but that's just a tool. May I suggest the following methodology to validate that this is all working properly:

• Take a snapshot of build scans at any commit. You can use any of the PRs, a build from trunk or make a small change and trigger CI in a draft PR.
• Merge these changes with that commit (for this reason, it might be cleanest to start with a draft PR as suggested above)
• Re-trigger the CI by pushing the changes
• Share the build scans for these in the PR description, or as a comment. (we don't need to compare every type of build, some of the important ones such as prototype build, instrumented tests etc should be enough) You can share screenshots to highlight some things, but the important thing is the build scans themselves.

I am suggesting this methodology because I believe it represents the differences the best. I also need this information to properly review this PR. However, if you'd like to use a different methodology, I don't want to impose. I can do this myself as part of the review. Hope that all makes sense and sound reasonable!