The GitHub Actions job "uv in /dev/breeze for cryptography - Update #1505299373" on airflow.git/main has failed. Run started by GitHub user dependabot[bot] (triggered by dependabot[bot]).
Head commit for run: 26d53bd1e84088bf7cb7ab11dcfde3d8e6b99048 / Jarek Potiuk <[email protected]> Resolve the constraints a release ships instead of tagging whatever exists (#71040) * Resolve the constraints a release ships instead of tagging whatever exists The constraints published with a version were whatever the constraints-X-Y branch happened to hold when the release ran - a resolution made by the last CI build, for the sources at that moment, rather than for the version being released. The candidate tagged that tip and the final release retagged the candidate, so no release ever resolved constraints of its own. A candidate now resolves them allowing pre-releases: the providers of the wave being voted on exist on PyPI only as rc versions, so constraints that refuse pre-releases cannot describe what a tester is asked to install. They land on a branch of the candidate's own, leaving the branch every other build reads where it was. The final release cannot promote those by retagging - a released version must never pin an rc - so it resolves the same set again, without pre-releases, and commits onto constraints-X-Y, which is what makes the released constraints the baseline everything downstream reads. Which of the two happens is derived from the version, so the stage cannot be set inconsistently with it. The work runs on CI runners rather than on the release manager's machine, which would otherwise need a CI image for every supported Python before it could cut a release, and is reachable on its own through `breeze workflow-run release-constraints` for redoing a candidate's constraints or producing them for a release cut before this existed. * Let only the providers answer with a pre-release `--pre` applies to the whole resolution, so a candidate's constraints could pin a pre-release of any dependency - a beta of some third-party library would end up in what a release ships, which is not what allowing rc providers was meant to permit. uv considers a pre-release for a package only when a requirement for it mentions one, so naming the providers with a pre-release lower bound confines the allowance to them and leaves every other package on the default policy. * State the pre-release scoping rather than leaning on uv's default The rc lower bounds already confined pre-releases to the providers, but only because uv's default strategy happens to permit them for explicitly marked packages. Naming `explicit` says that in the command instead of leaving it to a default that could change, and drops the `if-necessary` half of that default - the part that would let a package nobody marked resolve to a pre-release when no final version satisfies it. * Document what a release manager now sees at the constraints step The candidate half was undocumented - the release notes described only what the final release does, leaving a release manager to infer why a candidate suddenly grows a branch and a tag of its own, and why its constraints pin rc providers when nothing else in them is a pre-release. Both stages and the scope of the pre-release allowance are stated where each is reached. * Register the new constraints command where the docs checks look for it A command has to be grouped in its `*_commands_config.py` and embedded in one of the breeze docs, or the static checks reject it - `--allow-pre-releases` had no group and `workflow-run release-constraints` had a generated screenshot that nothing referenced. The two `setup` screenshots move because the command list they render is exactly what gained the new entry. Report URL: https://github.com/apache/airflow/actions/runs/30898219209 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
