Remove `cache-builder.yml` pipeline

[mokagio]

The changes from https://github.com/wordpress-mobile/gutenberg-mobile/pull/6719 make the need to build a Git cache unnecessary.

Testing: Ensure CI is green.

Ping @jkmassel to confirm this is the case also for the Apple Silicon CI.

My understanding is that it manages its own caching and doesn't need to read from the S3 bucket where this cache went. I say this based on looking at the pre-checkout and post-checkout hooks in the CI infra repo calling respectively hostmgr cache fetch-git-mirror and hostmgr cache publish-git-mirror. I also looked into hostmgr itself and, while I didn't go through the entire chain, my understanding there is that the Git mirror location is unrelated with what our git-s3-cache Buildkite plugin uses.

Related: https://github.com/Automattic/buildkite-ci/pull/382

---

PR submission checklist:

• [x] I have considered adding unit tests where possible. — This is a tooling PR.
• [x] I have considered if this change warrants user-facing release notes more info and have added them to RELEASE-NOTES.txt if necessary. — Not necessary.

[AliSoftware]

My understanding is that it manages its own caching and doesn't need to read from the S3 bucket where this cache went. I say this based on looking at the pre-checkout and post-checkout hooks in the CI infra repo calling respectively hostmgr cache fetch-git-mirror and hostmgr cache publish-git-mirror. I also looked into hostmgr itself and, while I didn't go through the entire chain, my understanding there is that the Git mirror location is unrelated with what our git-s3-cache Buildkite plugin uses.

This is correct.

• Our Apple Silicon Infra embeds the cache mechanism built-in, using our Synology Cache Server located in our rack in MacVault's data center as an intermediate cache which makes it way faster than fetching from S3 anyway.
• On the hosts, hostmgr will take care of checking the on-premises Synology Cache first, and only hit S3 on a Cache Miss from Synology. Both the S3 bucket and the Caddy HTTP Server to check are configured in the hostmgr.json config file.
• Our buildkite-agent.cfg config is then set up to use the git-mirrors (recent-ish) built-in feature of Buildkite, which basically internally does the same trick of using --reference during git clone as we used back in our git-s3-cache plugin
• In the VMs, we expose the host's /opt/ci/git-mirrors as a Shared Volume, then override the BUILDKITE_GIT_MIRRORS_PATH env var to /Volumes/My Shared Files/git-mirrors within the VM when we transfer the job from the host to the VM

PS: I should really copy that explanation above in the buildkite-ci repo (under docs/) at some point, will add it to my bucket list.

[AliSoftware]

PS: I should really copy that explanation above in the buildkite-ci repo (under docs/) at some point, will add it to my bucket list.

Done: https://github.com/Automattic/buildkite-ci/pull/383

[mokagio]

Thanks for the info @AliSoftware

[mokagio]

I'll wait to merge this till the infra one lands

[mokagio]

The CI infra change has been deployed. Merging.

Thanks again @AliSoftware for the reviews 🙇‍♂️