Closed codefromthecrypt closed 3 years ago
While true docker binaries disallow fetching windows from a different platform, the raw registry APIs can be used to surmount this.
For example, prioritizing down, the following will work with homebrew and also normal docker, regardless of platform:
curl -H 'Authorization: REGISTRY_SPECIFIC' \
-H 'Accept: application/vnd.docker.distribution.manifest.list.v2+json' \
-H 'Accept: application/vnd.docker.distribution.manifest.v1+prettyjws' \
-H 'Accept: application/vnd.oci.image.index.v1+json' \
https://$REGISTRY/v2/$REPOSITORY/manifests/$TAG
Ultimately, we want to fetch a application/vnd.oci.image.layer.v1.tar+gzip
and unzip what we need out of it.
There is some nuance, like we need to pick latest brew as conventions are different (ex 1.18.3-1 is the latest variant of 1.18.3), and also there is some weird scanning needed to avoid pulling all image layers especially on the massive windows docker image.
@mathetake I will be rewriting our shell scripts in go and solve all of this.. so that release config is simpler and no longer relies on knowing buildId from azure pipeline in order to get windows done.
I will be rewriting our shell scripts in go and solve all of this..
Nice! 🚀 🔥
Right now, we rely on multiple sources to prepare to archive a release. Using the currently not yet released v1.18.4 as an example:
For windows and linux, we need to lookup the buildId like this https://dev.azure.com/cncf/envoy/_build?view=runs&keywordFilter=v1.18.4 (this is an authenticated search, else we'd automate it)
For OSx, we have to ensure someone updated this with v1.18.4, or do that ourselves https://github.com/Homebrew/homebrew-core/blob/master/Formula/envoy.rb
only after that, can we archive the release (via a v1.18.4 tag here)
While this isn't huge effort, it is unnecessarily manual. Once tarballs are attached to Envoy releases (for all platforms), we should be able to fully automate this. See https://github.com/envoyproxy/envoy/issues/16830