[DO NOT MERGE][release] ray 2.56.0 windows image fix#64372
Open
elliot-barn wants to merge 3 commits into
Open
Conversation
…64034) Backport of #64034 to releases/2.56.0. The Windows base image build (ci/ray_ci/windows/build_base.sh) crashes when running `conda update -c conda-forge ca-certificates certifi`: AttributeError: module 'lib' has no attribute 'X509_V_FLAG_CB_ISSUER_CHECK' Upgrading the conda base env to python 3.10 (`conda install python=...`) pulls cryptography>=38, which removed `_lib.X509_V_FLAG_CB_ISSUER_CHECK`. pyopenssl is not part of that transaction, so the stale py3.8-era pyopenssl is left behind and still references the removed attribute at import. The next conda invocation imports requests -> urllib3.contrib.pyopenssl -> OpenSSL.crypto and detonates before conda can run, failing the base image build. Co-resolve pyopenssl 23.2.0 in the same conda install transaction so it stays compatible with the cryptography 38.x that gets installed, and --freeze-installed the cert update so it can't perturb the just-resolved env. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
…RGE) One-off release maneuver for shipping 2.56.0 Windows wheels. This branch's HEAD carries the windowsbuild conda fix (so the image builds), but the wheels must be stamped with the real release commit 637fd06, not this branch's commit. build-wheel-windows.sh stamps ray.__commit__ from BUILDKITE_COMMIT, which is forwarded into the build container via _DOCKER_ENV, so exporting it inside the windows wheel step overrides the stamp without affecting the checkout. Wheels will upload to s3://ray-wheels/<this-branch>/<release-commit>/ and then be copied into the releases/2.56.0/<release-commit>/ prefix for the PyPI upload. This commit is intentionally NOT for merge - drop it before opening the clean backport PR (which should contain only the build_base.sh fix). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates the Windows build configuration by adding pyopenssl and the --freeze-installed flag to the conda setup in build_base.sh. It also introduces a temporary release-build override in windows.rayci.yml. The reviewer correctly pointed out that this temporary override must be removed before merging.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Comment on lines
+42
to
+46
| # RELEASE-BUILD OVERRIDE (DO NOT MERGE): stamp the wheels with the real 2.56.0 | ||
| # release commit, even though this branch's HEAD carries the windowsbuild fix. | ||
| # build-wheel-windows.sh reads BUILDKITE_COMMIT for ray.__commit__; the env is | ||
| # forwarded into the container via _DOCKER_ENV. Drop this line for the clean PR. | ||
| - export BUILDKITE_COMMIT=637fd062205393b9e1929996bfe1d49bd3f8469d |
Contributor
There was a problem hiding this comment.
The temporary release-build override ('export BUILDKITE_COMMIT=...') and its associated comments should be removed before merging this pull request to prevent hardcoding the commit hash for future builds on this branch.
Adds export BUILDKITE_BRANCH=releases/2.56.0 inside the windows wheel step so the
postmerge upload broker (.buildkite/copy_files.py, key = {BUILDKITE_BRANCH}/{BUILDKITE_COMMIT}/{fn})
writes the wheels straight to s3://ray-wheels/releases/2.56.0/637fd062.../ -- the
same prefix the release PyPI upload reads from. There is no direct write access to
the cross-account ray-wheels bucket, so routing via BUILDKITE_BRANCH is the only
way to land them in the release prefix.
Stacks on top of the BUILDKITE_COMMIT override; both TEMP commits are dropped
before the clean build_base.sh backport PR.
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
elliot-barn
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #64034 to
releases/2.56.0.The Windows base image build (
ci/ray_ci/windows/build_base.sh) crashes during theconda update -c conda-forge ca-certificates certifistep:cryptography>=38, which removed_lib.X509_V_FLAG_CB_ISSUER_CHECK.pyopensslis notpart of that transaction, so the stale py3.8-era
pyopensslis left behind and stillreferences the removed attribute at import. The next conda invocation imports
requests -> urllib3.contrib.pyopenssl -> OpenSSL.cryptoand detonates before conda canrun, failing the
windowsbuildimage build — which in turn cascades every Windows testand the Windows wheel jobs into
waiting_failed.This is already fixed on
master(#64034); the release branch never received it, so the2.56.0 postmerge build produced no Windows wheels.
What's changed
ci/ray_ci/windows/build_base.shonly:pyopenssl=23.2.0in the sameconda installtransaction as the Pythonupgrade, so it stays compatible with the
cryptography38.x that gets installed.--freeze-installedto theca-certificates/certifiupdate so it can't perturbthe just-resolved env.