[v3-3-test] Allow manual triggering of constraints refresh workflow (#69457)#69461
Merged
Conversation
…69457) Constraints in the constraints-* branches only refresh automatically when uv.lock changes on a stable branch. After a providers release there is no such push, so refreshing constraints - for example to pick up newly released providers before promoting an RC - required running the breeze constraint-generation commands locally. Add a workflow_dispatch trigger to the update-constraints workflow. The manual run is launched from main and takes a `ref` input (branch, tag or commit hash) selecting the sources to refresh constraints from; the target constraints-X-Y branch is derived from that ref's branch_defaults.py. This avoids cherry-picking the workflow to vX-Y-test / vX-Y-stable, which matters because those branches diverge while RCs are being voted on. A toggle re-resolves to the newest matching dependencies from PyPI (default on). The ref is threaded through the reusable ci-image-build and generate-constraints workflows via a new optional checkout-ref input (backward compatible for existing callers). Because the RC constraints are frozen when the RC is cut, start-release now asks whether to base the final constraints-<version> tag on the latest constraints-X-Y branch tip (when refreshed after the last RC) instead of the RC tag. The manual procedure and release-guide note are documented accordingly. (cherry picked from commit 271604f) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
1 task
vatsrahul1001
pushed a commit
that referenced
this pull request
Jul 7, 2026
…69457) (#69461) Constraints in the constraints-* branches only refresh automatically when uv.lock changes on a stable branch. After a providers release there is no such push, so refreshing constraints - for example to pick up newly released providers before promoting an RC - required running the breeze constraint-generation commands locally. Add a workflow_dispatch trigger to the update-constraints workflow. The manual run is launched from main and takes a `ref` input (branch, tag or commit hash) selecting the sources to refresh constraints from; the target constraints-X-Y branch is derived from that ref's branch_defaults.py. This avoids cherry-picking the workflow to vX-Y-test / vX-Y-stable, which matters because those branches diverge while RCs are being voted on. A toggle re-resolves to the newest matching dependencies from PyPI (default on). The ref is threaded through the reusable ci-image-build and generate-constraints workflows via a new optional checkout-ref input (backward compatible for existing callers). Because the RC constraints are frozen when the RC is cut, start-release now asks whether to base the final constraints-<version> tag on the latest constraints-X-Y branch tip (when refreshed after the last RC) instead of the RC tag. The manual procedure and release-guide note are documented accordingly. (cherry picked from commit 271604f) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
vatsrahul1001
pushed a commit
that referenced
this pull request
Jul 9, 2026
…69457) (#69461) Constraints in the constraints-* branches only refresh automatically when uv.lock changes on a stable branch. After a providers release there is no such push, so refreshing constraints - for example to pick up newly released providers before promoting an RC - required running the breeze constraint-generation commands locally. Add a workflow_dispatch trigger to the update-constraints workflow. The manual run is launched from main and takes a `ref` input (branch, tag or commit hash) selecting the sources to refresh constraints from; the target constraints-X-Y branch is derived from that ref's branch_defaults.py. This avoids cherry-picking the workflow to vX-Y-test / vX-Y-stable, which matters because those branches diverge while RCs are being voted on. A toggle re-resolves to the newest matching dependencies from PyPI (default on). The ref is threaded through the reusable ci-image-build and generate-constraints workflows via a new optional checkout-ref input (backward compatible for existing callers). Because the RC constraints are frozen when the RC is cut, start-release now asks whether to base the final constraints-<version> tag on the latest constraints-X-Y branch tip (when refreshed after the last RC) instead of the RC tag. The manual procedure and release-guide note are documented accordingly. (cherry picked from commit 271604f) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
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
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.
Constraints in the constraints-* branches only refresh automatically when
uv.lock changes on a stable branch. After a providers release there is no such
push, so refreshing constraints - for example to pick up newly released
providers before promoting an RC - required running the breeze
constraint-generation commands locally.
Add a workflow_dispatch trigger to the update-constraints workflow. The manual
run is launched from main and takes a
refinput (branch, tag or commit hash)selecting the sources to refresh constraints from; the target constraints-X-Y
branch is derived from that ref's branch_defaults.py. This avoids cherry-picking
the workflow to vX-Y-test / vX-Y-stable, which matters because those branches
diverge while RCs are being voted on. A toggle re-resolves to the newest
matching dependencies from PyPI (default on). The ref is threaded through the
reusable ci-image-build and generate-constraints workflows via a new optional
checkout-ref input (backward compatible for existing callers).
Because the RC constraints are frozen when the RC is cut, start-release now asks
whether to base the final constraints- tag on the latest constraints-X-Y
branch tip (when refreshed after the last RC) instead of the RC tag.
The manual procedure and release-guide note are documented accordingly.
(cherry picked from commit 271604f)
Co-authored-by: Jarek Potiuk jarek@potiuk.com