[Buildkite] Test Android Staging on ami-0953ca1d949c23a58 -> ami-0f976e0b4de96aa28

[ParaskP7]

Related: a8c-ci-toolkit-buildkite-plugin##142

AMI Name: android-build-image-6.12.0v1.5-rc-1

Description

This PR changes the Buildkite agent from android to android-staging. This change is not meant to be merged, but rather used to verify that the new AMI ami-0953ca1d949c23a58 works as expected.

---

Before the Change

---

• Saving Gradle dependency cache...
  • Duration: 0 minutes and 43 seconds
  • Cache Size: 628.98 MB
• Build Time: 20m 28s

---

• Restoring Gradle dependency cache...
  • Duration: 0 minutes and 14 seconds
  • Cache Size: 628.98 MB
• Build (Lint): Build Scan -> Network Activity*
  • Files Downloaded: 12
  • Network Requests: 37
  • Time Spent: 4s

(*) Although, note that these numbers might not be very representative because trunk is using a dependency cache that is already outdated (5 days has passed since it was last updated, every Sunday).

---

After the Change

---

• Saving Gradle dependency cache...
  • Duration: 1 minutes and 12 seconds
  • Cache Size: 950.32 MB
• Build Time: 7m 14s

---

• Restoring Gradle dependency cache...
  • Duration: 0 minutes and 19 seconds
  • Cache Size: 950.32 MB
• Build (Lint): Build Scan -> Network Activity
  • Files Downloaded: 0
  • Network Requests: 0
  • Time Spent: 0

---

Conclusions

As expected, using ./gradlew downloadDependencies androidDependencies is:

1. Simpler, much less configuration and reasoning about which tasks to use.
2. Scalable, no need to add any more tasks to the save-cache.sh script as the project evolves.
3. Producing a bigger cache,
   • Before: 628.98 MB
   • After: 950.32 MB
   • Result: + 321.34 MB more data downloaded, which means even less network requests on CI.
4. Slower, both in saving and restoring the cache, which is the only drawable:
   • Save:
     • Before: 0 minutes and 43 seconds
     • After: 1 minutes and 12 seconds
     • Result: + 29 seconds to save the cache.
   • Restore:
     • Before: 0 minutes and 14 seconds
     • After: 0 minutes and 19 seconds
     • Result: + 5 seconds to restore the cache.

[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-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	2f4941b
	Direct Download	woocommerce-wear-prototype-build-pr13387-2f4941b.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	2f4941b
	Direct Download	woocommerce-prototype-build-pr13387-2f4941b.apk

[ParaskP7]

👋 @wzieba , I just added you as a review on this draft PR, to be closed when we get ready with the new Android AMI, but please, take a look at the description (results). 🙏

TL;DR: Everything is working as expected, a total win, I am happy with the result, with the only drawback that it now takes more time to save and restore the cache.

• During saving, this is actually irrelevant as the total build time dropped anyway.
• But, during restoring, you add an additional 5s to 10s, which is indeed something we expected, but worth noticing/thinking about anyway. 👀

[wzieba]

But, during restoring, you add an additional 5s to 10s, which is indeed something we expected, but worth noticing/thinking about anyway. 👀

Yeah, thanks for highlighting this! It's unfortunate and might even change in which jobs we use the dependency cache, but so low cost of maintaining the "save-cache" script across projects is I think worth these 5-10s.

[ParaskP7]

Yeah, thanks for highlighting this! It's unfortunate and might even change in which jobs we use the dependency cache, but so low cost of maintaining the "save-cache" script across projects is I think worth these 5-10s.

Btw @wzieba , forgot to say that I agree with what you say here, and worse case we could revert back to using the assemble tasks for saving the cache, or just the assembleDebugAndroidTest, and switching between solutions as we see fit. 👍