Use folder tagged docker images for binary builds #151706
Conversation
clee2000
added
the
ciflow/binaries
| DEFAULT_TAG = os.getenv("RELEASE_VERSION_TAG", "main") | ||
|
|
||
| WHEEL_CONTAINER_IMAGES = { | ||
| **{gpu_arch: f"manylinux2_28-builder:cuda{gpu_arch}" for gpu_arch in CUDA_ARCHES}, |
There was a problem hiding this comment.
| **{gpu_arch: f"manylinux2_28-builder:cuda{gpu_arch}" for gpu_arch in CUDA_ARCHES}, | |
| **{gpu_arch: f"wheel-builder:cuda{gpu_arch}" for gpu_arch in CUDA_ARCHES}, |
nit: but can we just name these something that's easier to type
There was a problem hiding this comment.
When we are going to update to next wheel build platform I think we would need to keep the old wheels and introduce the new ones. Hence having manylinux version as in pypi package comes handy
|
@pytorchbot merge -f "no trunk needed" |
Merge startedYour change will be merged immediately since you used the force (-f) flag, bypassing any CI checks (ETA: 1-5 minutes). Please use Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
Should be the last part of #150558, except for maybe s390x stuff, which I'm still not sure what's going on there
For binary builds, do the thing like we do in CI where we tag each image with a hash of the .ci/docker folder to ensure a docker image built from that commit gets used. Previously it would use imagename:arch-main, which could be a version of the image based on an older commit
After this, changing a docker image and then tagging with ciflow/binaries on the same PR should use the new docker images
Release and main builds should still pull from docker io
Cons: