CI: Don't run bootstrap if we restored from cache

[ksperling-apple]

Handle caching and log upload directly within the bootstrap action, and don't perform the actual bootstrap if we have a cache hit. Include the platform name in the cache key.

[andy31415]

@ksperling-apple do you happen to know how large our storage allocation for caching is? I believe our bootstrap includes cipd images for clang at least, so it may be quite large, so if we multiply it by the number of platforms we may increase the storage a lot. My current PW_ENVIRONMENT_ROOT on linux is 5.2GB. In setup we seem to have 15 separate requirements.txt.

[andy31415]

@ksperling-apple do you happen to know how large our storage allocation for caching is? I believe our bootstrap includes cipd images for clang at least, so it may be quite large, so if we multiply it by the number of platforms we may increase the storage a lot. My current PW_ENVIRONMENT_ROOT on linux is 5.2GB. In setup we seem to have 15 separate requirements.txt.

https://buildjet.com/for-github-actions/docs/about/pricing#build-jet-cache-limits says 20GB per week. this seems to work with 5GB, but will not work with 75.

[ksperling-apple]

@ksperling-apple do you happen to know how large our storage allocation for caching is? I believe our bootstrap includes cipd images for clang at least, so it may be quite large, so if we multiply it by the number of platforms we may increase the storage a lot. My current PW_ENVIRONMENT_ROOT on linux is 5.2GB. In setup we seem to have 15 separate requirements.txt.

https://buildjet.com/for-github-actions/docs/about/pricing#build-jet-cache-limits says 20GB per week. this seems to work with 5GB, but will not work with 75.

At the moment I'm seeing cache sizes around 1.5-2 GB (tar ball size) in the logs, so I think we should be OK for the time being. If we're starting to hit the limit we can look at bootstrapping for all platforms instead of the targeted platform, so we have one large cache file shared by all jobs.