Skip to content

[v3-3-test] Allow manual triggering of constraints refresh workflow (#69457)#69461

Merged
potiuk merged 1 commit into
v3-3-testfrom
backport-271604f-v3-3-test
Jul 6, 2026
Merged

[v3-3-test] Allow manual triggering of constraints refresh workflow (#69457)#69461
potiuk merged 1 commit into
v3-3-testfrom
backport-271604f-v3-3-test

Conversation

@github-actions

@github-actions github-actions Bot commented Jul 6, 2026

Copy link
Copy Markdown
Contributor

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- 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

…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>
@potiuk potiuk marked this pull request as ready for review July 6, 2026 20:04
@potiuk potiuk merged commit 1276cd9 into v3-3-test Jul 6, 2026
32 of 41 checks passed
@potiuk potiuk deleted the backport-271604f-v3-3-test branch July 6, 2026 20:04
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant