Run CI on airflow-ctl release-branch pull requests and pushes by Lee-W · Pull Request #70726 · apache/airflow

Lee-W · 2026-07-30T08:51:34Z

Pull requests targeting this branch receive no CI at all today: the
airflow-ctl/ release-branch patterns are missing from this branch's workflow
trigger filters, so only branch-independent bot checks report and a PR can show
all-green without any tests or CodeQL ever running.

GitHub resolves trigger filters from the workflow files on the target branch,
so the equivalent fix on main (#69626) is a no-op here and has to land on the
release branch itself.

Same change as the companion PR against airflow-ctl/v0-1-test (#70724).

related: #69626

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

Pull requests targeting this branch received no CI at all: the airflow-ctl release-branch patterns were missing from the workflow trigger filters, so only branch-independent bot checks reported and a PR could show all-green without any tests or CodeQL ever running. GitHub resolves trigger filters from the workflow files on the target branch, so the equivalent fix on main (apache#69626) does not apply here and has to land on the release branch itself.

The ASF organisation-level Actions allowlist no longer permits the af78098f (v3.0.1) pin, and GitHub blocks the entire workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all and asf-allowlist-check reports the pin directly. v3.0.3 is already allowlisted and in use on chart/v1-2x-test, and stays within the same major version so the step inputs are unchanged.

The ASF organisation-level Actions allowlist no longer permits the pins this branch carries for astral-sh/setup-uv and aws-actions/configure-aws-credentials, and GitHub blocks the whole workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all. These are the last two allowlist violations on the branch; the pins chosen are the ones chart/v1-2x-test already runs green with, so they are known to be both allowlisted and compatible with workflows of this vintage.

The "airflow-ctl 0.1.5: test to stable" sync (apache#67294) copied main's airflow-core/pyproject.toml metadata onto this branch without the matching sources. Three leftovers stayed behind: - the distribution version became 3.3.0 while airflow-core/src/airflow/__init__.py stayed 3.2.1 - the Task SDK requirement became >=1.3.0,<1.4.0 while task-sdk on this branch is 1.2.1 - a force-include and a shared_distributions entry appeared for apache-airflow-shared-state, which has no shared/state folder here Once CI actually started running on this branch, the CI image build failed pip check on the resulting triangle: apache-airflow 3.2.1 has requirement apache-airflow-core==3.2.1, but you have apache-airflow-core 3.3.0 apache-airflow-core 3.3.0 has requirement apache-airflow-task-sdk<1.4.0,>=1.3.0, but you have 1.2.1 apache-airflow-task-sdk 1.2.1 has requirement apache-airflow-core<3.3.0,>=3.2.0, but you have 3.3.0 Realign the metadata with the sources that are on the branch, which is what check-version-consistency and check-shared-distributions-usage already expect, and refresh uv.lock, which had drifted from the same sync.

The same test-to-stable sync (apache#67294) repointed the mypy-airflow-ctl hook at ../scripts/ci/prek/run_mypy_full_dist_local_venv_or_breeze_in_ci.py, which only exists on main. On this branch prek dies before mypy runs: error: Failed to run hook `mypy-airflow-ctl` caused by: Run command `python hook` failed caused by: No such file or directory (os error 2) Point it back at mypy_local_folder.py, which is what airflow-core, task-sdk, devel-common and dev/scripts all use on this branch.

The test-to-stable sync (apache#67294) copied airflowctl's generated datamodels from main, so they describe Airflow 3.3's API while this branch ships core 3.2.1. Two consequences, both red once CI started running here: - generate-airflowctl-datamodels regenerates from ../airflow-core/src/airflow/api_fastapi and fails on any drift, so Static checks could never pass - the models required is_backfillable and timetable_periodic, which apache#64644 added in 3.3.0, so every single-object Dag response failed validation against this branch's own PROD image: ValidationError: 2 validation errors for DAGResponse is_backfillable Field required timetable_periodic Field required Run the hook to bring the models back in line with the spec on this branch. This drops 14 model classes that no airflowctl code or test references, plus the 3.3-only fields above. Note RELEASE_NOTES.rst credits "Add ``is_backfillable`` property to DAG API responses (apache#64644)" to airflowctl 0.1.5, but apache#64644 touches only airflow-core -- that line is sync noise, not a client feature.

Lee-W · 2026-08-05T09:39:40Z

since this PR only turn on the CI check and the fix should first be merged into v0-1-test and then back to v0-1-stable. the fix is now in v0-1-test. I'll merge this one now. and the ci will be green once we do another ctl release

Lee-W · 2026-07-30T08:51:34Z

Pull requests targeting this branch receive no CI at all today: the
airflow-ctl/ release-branch patterns are missing from this branch's workflow
trigger filters, so only branch-independent bot checks report and a PR can show
all-green without any tests or CodeQL ever running.

GitHub resolves trigger filters from the workflow files on the target branch,
so the equivalent fix on main (#69626) is a no-op here and has to land on the
release branch itself.

Same change as the companion PR against airflow-ctl/v0-1-test (#70724).

related: #69626

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

Pull requests targeting this branch received no CI at all: the airflow-ctl release-branch patterns were missing from the workflow trigger filters, so only branch-independent bot checks reported and a PR could show all-green without any tests or CodeQL ever running. GitHub resolves trigger filters from the workflow files on the target branch, so the equivalent fix on main (apache#69626) does not apply here and has to land on the release branch itself.

The ASF organisation-level Actions allowlist no longer permits the af78098f (v3.0.1) pin, and GitHub blocks the entire workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all and asf-allowlist-check reports the pin directly. v3.0.3 is already allowlisted and in use on chart/v1-2x-test, and stays within the same major version so the step inputs are unchanged.

The ASF organisation-level Actions allowlist no longer permits the pins this branch carries for astral-sh/setup-uv and aws-actions/configure-aws-credentials, and GitHub blocks the whole workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all. These are the last two allowlist violations on the branch; the pins chosen are the ones chart/v1-2x-test already runs green with, so they are known to be both allowlisted and compatible with workflows of this vintage.

The "airflow-ctl 0.1.5: test to stable" sync (apache#67294) copied main's airflow-core/pyproject.toml metadata onto this branch without the matching sources. Three leftovers stayed behind: - the distribution version became 3.3.0 while airflow-core/src/airflow/__init__.py stayed 3.2.1 - the Task SDK requirement became >=1.3.0,<1.4.0 while task-sdk on this branch is 1.2.1 - a force-include and a shared_distributions entry appeared for apache-airflow-shared-state, which has no shared/state folder here Once CI actually started running on this branch, the CI image build failed pip check on the resulting triangle: apache-airflow 3.2.1 has requirement apache-airflow-core==3.2.1, but you have apache-airflow-core 3.3.0 apache-airflow-core 3.3.0 has requirement apache-airflow-task-sdk<1.4.0,>=1.3.0, but you have 1.2.1 apache-airflow-task-sdk 1.2.1 has requirement apache-airflow-core<3.3.0,>=3.2.0, but you have 3.3.0 Realign the metadata with the sources that are on the branch, which is what check-version-consistency and check-shared-distributions-usage already expect, and refresh uv.lock, which had drifted from the same sync.

The same test-to-stable sync (apache#67294) repointed the mypy-airflow-ctl hook at ../scripts/ci/prek/run_mypy_full_dist_local_venv_or_breeze_in_ci.py, which only exists on main. On this branch prek dies before mypy runs: error: Failed to run hook `mypy-airflow-ctl` caused by: Run command `python hook` failed caused by: No such file or directory (os error 2) Point it back at mypy_local_folder.py, which is what airflow-core, task-sdk, devel-common and dev/scripts all use on this branch.

The test-to-stable sync (apache#67294) copied airflowctl's generated datamodels from main, so they describe Airflow 3.3's API while this branch ships core 3.2.1. Two consequences, both red once CI started running here: - generate-airflowctl-datamodels regenerates from ../airflow-core/src/airflow/api_fastapi and fails on any drift, so Static checks could never pass - the models required is_backfillable and timetable_periodic, which apache#64644 added in 3.3.0, so every single-object Dag response failed validation against this branch's own PROD image: ValidationError: 2 validation errors for DAGResponse is_backfillable Field required timetable_periodic Field required Run the hook to bring the models back in line with the spec on this branch. This drops 14 model classes that no airflowctl code or test references, plus the 3.3-only fields above. Note RELEASE_NOTES.rst credits "Add ``is_backfillable`` property to DAG API responses (apache#64644)" to airflowctl 0.1.5, but apache#64644 touches only airflow-core -- that line is sync noise, not a client feature.

Lee-W · 2026-08-05T09:39:40Z

since this PR only turn on the CI check and the fix should first be merged into v0-1-test and then back to v0-1-stable. the fix is now in v0-1-test. I'll merge this one now. and the ci will be green once we do another ctl release

Lee-W · 2026-07-30T08:51:34Z

Pull requests targeting this branch receive no CI at all today: the
airflow-ctl/ release-branch patterns are missing from this branch's workflow
trigger filters, so only branch-independent bot checks report and a PR can show
all-green without any tests or CodeQL ever running.

GitHub resolves trigger filters from the workflow files on the target branch,
so the equivalent fix on main (#69626) is a no-op here and has to land on the
release branch itself.

Same change as the companion PR against airflow-ctl/v0-1-test (#70724).

related: #69626

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

Pull requests targeting this branch received no CI at all: the airflow-ctl release-branch patterns were missing from the workflow trigger filters, so only branch-independent bot checks reported and a PR could show all-green without any tests or CodeQL ever running. GitHub resolves trigger filters from the workflow files on the target branch, so the equivalent fix on main (apache#69626) does not apply here and has to land on the release branch itself.

The ASF organisation-level Actions allowlist no longer permits the af78098f (v3.0.1) pin, and GitHub blocks the entire workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all and asf-allowlist-check reports the pin directly. v3.0.3 is already allowlisted and in use on chart/v1-2x-test, and stays within the same major version so the step inputs are unchanged.

The ASF organisation-level Actions allowlist no longer permits the pins this branch carries for astral-sh/setup-uv and aws-actions/configure-aws-credentials, and GitHub blocks the whole workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all. These are the last two allowlist violations on the branch; the pins chosen are the ones chart/v1-2x-test already runs green with, so they are known to be both allowlisted and compatible with workflows of this vintage.

The "airflow-ctl 0.1.5: test to stable" sync (apache#67294) copied main's airflow-core/pyproject.toml metadata onto this branch without the matching sources. Three leftovers stayed behind: - the distribution version became 3.3.0 while airflow-core/src/airflow/__init__.py stayed 3.2.1 - the Task SDK requirement became >=1.3.0,<1.4.0 while task-sdk on this branch is 1.2.1 - a force-include and a shared_distributions entry appeared for apache-airflow-shared-state, which has no shared/state folder here Once CI actually started running on this branch, the CI image build failed pip check on the resulting triangle: apache-airflow 3.2.1 has requirement apache-airflow-core==3.2.1, but you have apache-airflow-core 3.3.0 apache-airflow-core 3.3.0 has requirement apache-airflow-task-sdk<1.4.0,>=1.3.0, but you have 1.2.1 apache-airflow-task-sdk 1.2.1 has requirement apache-airflow-core<3.3.0,>=3.2.0, but you have 3.3.0 Realign the metadata with the sources that are on the branch, which is what check-version-consistency and check-shared-distributions-usage already expect, and refresh uv.lock, which had drifted from the same sync.

The same test-to-stable sync (apache#67294) repointed the mypy-airflow-ctl hook at ../scripts/ci/prek/run_mypy_full_dist_local_venv_or_breeze_in_ci.py, which only exists on main. On this branch prek dies before mypy runs: error: Failed to run hook `mypy-airflow-ctl` caused by: Run command `python hook` failed caused by: No such file or directory (os error 2) Point it back at mypy_local_folder.py, which is what airflow-core, task-sdk, devel-common and dev/scripts all use on this branch.

The test-to-stable sync (apache#67294) copied airflowctl's generated datamodels from main, so they describe Airflow 3.3's API while this branch ships core 3.2.1. Two consequences, both red once CI started running here: - generate-airflowctl-datamodels regenerates from ../airflow-core/src/airflow/api_fastapi and fails on any drift, so Static checks could never pass - the models required is_backfillable and timetable_periodic, which apache#64644 added in 3.3.0, so every single-object Dag response failed validation against this branch's own PROD image: ValidationError: 2 validation errors for DAGResponse is_backfillable Field required timetable_periodic Field required Run the hook to bring the models back in line with the spec on this branch. This drops 14 model classes that no airflowctl code or test references, plus the 3.3-only fields above. Note RELEASE_NOTES.rst credits "Add ``is_backfillable`` property to DAG API responses (apache#64644)" to airflowctl 0.1.5, but apache#64644 touches only airflow-core -- that line is sync noise, not a client feature.

Lee-W · 2026-08-05T09:39:40Z

since this PR only turn on the CI check and the fix should first be merged into v0-1-test and then back to v0-1-stable. the fix is now in v0-1-test. I'll merge this one now. and the ci will be green once we do another ctl release

Lee-W · 2026-07-30T08:51:34Z

Pull requests targeting this branch receive no CI at all today: the
airflow-ctl/ release-branch patterns are missing from this branch's workflow
trigger filters, so only branch-independent bot checks report and a PR can show
all-green without any tests or CodeQL ever running.

GitHub resolves trigger filters from the workflow files on the target branch,
so the equivalent fix on main (#69626) is a no-op here and has to land on the
release branch itself.

Same change as the companion PR against airflow-ctl/v0-1-test (#70724).

related: #69626

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

Pull requests targeting this branch received no CI at all: the airflow-ctl release-branch patterns were missing from the workflow trigger filters, so only branch-independent bot checks reported and a PR could show all-green without any tests or CodeQL ever running. GitHub resolves trigger filters from the workflow files on the target branch, so the equivalent fix on main (apache#69626) does not apply here and has to land on the release branch itself.

The ASF organisation-level Actions allowlist no longer permits the af78098f (v3.0.1) pin, and GitHub blocks the entire workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all and asf-allowlist-check reports the pin directly. v3.0.3 is already allowlisted and in use on chart/v1-2x-test, and stays within the same major version so the step inputs are unchanged.

The ASF organisation-level Actions allowlist no longer permits the pins this branch carries for astral-sh/setup-uv and aws-actions/configure-aws-credentials, and GitHub blocks the whole workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all. These are the last two allowlist violations on the branch; the pins chosen are the ones chart/v1-2x-test already runs green with, so they are known to be both allowlisted and compatible with workflows of this vintage.

The "airflow-ctl 0.1.5: test to stable" sync (apache#67294) copied main's airflow-core/pyproject.toml metadata onto this branch without the matching sources. Three leftovers stayed behind: - the distribution version became 3.3.0 while airflow-core/src/airflow/__init__.py stayed 3.2.1 - the Task SDK requirement became >=1.3.0,<1.4.0 while task-sdk on this branch is 1.2.1 - a force-include and a shared_distributions entry appeared for apache-airflow-shared-state, which has no shared/state folder here Once CI actually started running on this branch, the CI image build failed pip check on the resulting triangle: apache-airflow 3.2.1 has requirement apache-airflow-core==3.2.1, but you have apache-airflow-core 3.3.0 apache-airflow-core 3.3.0 has requirement apache-airflow-task-sdk<1.4.0,>=1.3.0, but you have 1.2.1 apache-airflow-task-sdk 1.2.1 has requirement apache-airflow-core<3.3.0,>=3.2.0, but you have 3.3.0 Realign the metadata with the sources that are on the branch, which is what check-version-consistency and check-shared-distributions-usage already expect, and refresh uv.lock, which had drifted from the same sync.

The same test-to-stable sync (apache#67294) repointed the mypy-airflow-ctl hook at ../scripts/ci/prek/run_mypy_full_dist_local_venv_or_breeze_in_ci.py, which only exists on main. On this branch prek dies before mypy runs: error: Failed to run hook `mypy-airflow-ctl` caused by: Run command `python hook` failed caused by: No such file or directory (os error 2) Point it back at mypy_local_folder.py, which is what airflow-core, task-sdk, devel-common and dev/scripts all use on this branch.

The test-to-stable sync (apache#67294) copied airflowctl's generated datamodels from main, so they describe Airflow 3.3's API while this branch ships core 3.2.1. Two consequences, both red once CI started running here: - generate-airflowctl-datamodels regenerates from ../airflow-core/src/airflow/api_fastapi and fails on any drift, so Static checks could never pass - the models required is_backfillable and timetable_periodic, which apache#64644 added in 3.3.0, so every single-object Dag response failed validation against this branch's own PROD image: ValidationError: 2 validation errors for DAGResponse is_backfillable Field required timetable_periodic Field required Run the hook to bring the models back in line with the spec on this branch. This drops 14 model classes that no airflowctl code or test references, plus the 3.3-only fields above. Note RELEASE_NOTES.rst credits "Add ``is_backfillable`` property to DAG API responses (apache#64644)" to airflowctl 0.1.5, but apache#64644 touches only airflow-core -- that line is sync noise, not a client feature.

Lee-W · 2026-08-05T09:39:40Z

since this PR only turn on the CI check and the fix should first be merged into v0-1-test and then back to v0-1-stable. the fix is now in v0-1-test. I'll merge this one now. and the ci will be green once we do another ctl release

Lee-W · 2026-07-30T08:51:34Z

Pull requests targeting this branch receive no CI at all today: the
airflow-ctl/ release-branch patterns are missing from this branch's workflow
trigger filters, so only branch-independent bot checks report and a PR can show
all-green without any tests or CodeQL ever running.

GitHub resolves trigger filters from the workflow files on the target branch,
so the equivalent fix on main (#69626) is a no-op here and has to land on the
release branch itself.

Same change as the companion PR against airflow-ctl/v0-1-test (#70724).

related: #69626

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

Pull requests targeting this branch received no CI at all: the airflow-ctl release-branch patterns were missing from the workflow trigger filters, so only branch-independent bot checks reported and a PR could show all-green without any tests or CodeQL ever running. GitHub resolves trigger filters from the workflow files on the target branch, so the equivalent fix on main (apache#69626) does not apply here and has to land on the release branch itself.

The ASF organisation-level Actions allowlist no longer permits the af78098f (v3.0.1) pin, and GitHub blocks the entire workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all and asf-allowlist-check reports the pin directly. v3.0.3 is already allowlisted and in use on chart/v1-2x-test, and stays within the same major version so the step inputs are unchanged.

The ASF organisation-level Actions allowlist no longer permits the pins this branch carries for astral-sh/setup-uv and aws-actions/configure-aws-credentials, and GitHub blocks the whole workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all. These are the last two allowlist violations on the branch; the pins chosen are the ones chart/v1-2x-test already runs green with, so they are known to be both allowlisted and compatible with workflows of this vintage.

The "airflow-ctl 0.1.5: test to stable" sync (apache#67294) copied main's airflow-core/pyproject.toml metadata onto this branch without the matching sources. Three leftovers stayed behind: - the distribution version became 3.3.0 while airflow-core/src/airflow/__init__.py stayed 3.2.1 - the Task SDK requirement became >=1.3.0,<1.4.0 while task-sdk on this branch is 1.2.1 - a force-include and a shared_distributions entry appeared for apache-airflow-shared-state, which has no shared/state folder here Once CI actually started running on this branch, the CI image build failed pip check on the resulting triangle: apache-airflow 3.2.1 has requirement apache-airflow-core==3.2.1, but you have apache-airflow-core 3.3.0 apache-airflow-core 3.3.0 has requirement apache-airflow-task-sdk<1.4.0,>=1.3.0, but you have 1.2.1 apache-airflow-task-sdk 1.2.1 has requirement apache-airflow-core<3.3.0,>=3.2.0, but you have 3.3.0 Realign the metadata with the sources that are on the branch, which is what check-version-consistency and check-shared-distributions-usage already expect, and refresh uv.lock, which had drifted from the same sync.

The same test-to-stable sync (apache#67294) repointed the mypy-airflow-ctl hook at ../scripts/ci/prek/run_mypy_full_dist_local_venv_or_breeze_in_ci.py, which only exists on main. On this branch prek dies before mypy runs: error: Failed to run hook `mypy-airflow-ctl` caused by: Run command `python hook` failed caused by: No such file or directory (os error 2) Point it back at mypy_local_folder.py, which is what airflow-core, task-sdk, devel-common and dev/scripts all use on this branch.

The test-to-stable sync (apache#67294) copied airflowctl's generated datamodels from main, so they describe Airflow 3.3's API while this branch ships core 3.2.1. Two consequences, both red once CI started running here: - generate-airflowctl-datamodels regenerates from ../airflow-core/src/airflow/api_fastapi and fails on any drift, so Static checks could never pass - the models required is_backfillable and timetable_periodic, which apache#64644 added in 3.3.0, so every single-object Dag response failed validation against this branch's own PROD image: ValidationError: 2 validation errors for DAGResponse is_backfillable Field required timetable_periodic Field required Run the hook to bring the models back in line with the spec on this branch. This drops 14 model classes that no airflowctl code or test references, plus the 3.3-only fields above. Note RELEASE_NOTES.rst credits "Add ``is_backfillable`` property to DAG API responses (apache#64644)" to airflowctl 0.1.5, but apache#64644 touches only airflow-core -- that line is sync noise, not a client feature.

Lee-W · 2026-08-05T09:39:40Z

since this PR only turn on the CI check and the fix should first be merged into v0-1-test and then back to v0-1-stable. the fix is now in v0-1-test. I'll merge this one now. and the ci will be green once we do another ctl release

Lee-W · 2026-07-30T08:51:34Z

Pull requests targeting this branch receive no CI at all today: the
airflow-ctl/ release-branch patterns are missing from this branch's workflow
trigger filters, so only branch-independent bot checks report and a PR can show
all-green without any tests or CodeQL ever running.

GitHub resolves trigger filters from the workflow files on the target branch,
so the equivalent fix on main (#69626) is a no-op here and has to land on the
release branch itself.

Same change as the companion PR against airflow-ctl/v0-1-test (#70724).

related: #69626

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

Pull requests targeting this branch received no CI at all: the airflow-ctl release-branch patterns were missing from the workflow trigger filters, so only branch-independent bot checks reported and a PR could show all-green without any tests or CodeQL ever running. GitHub resolves trigger filters from the workflow files on the target branch, so the equivalent fix on main (apache#69626) does not apply here and has to land on the release branch itself.

The ASF organisation-level Actions allowlist no longer permits the af78098f (v3.0.1) pin, and GitHub blocks the entire workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all and asf-allowlist-check reports the pin directly. v3.0.3 is already allowlisted and in use on chart/v1-2x-test, and stays within the same major version so the step inputs are unchanged.

The ASF organisation-level Actions allowlist no longer permits the pins this branch carries for astral-sh/setup-uv and aws-actions/configure-aws-credentials, and GitHub blocks the whole workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all. These are the last two allowlist violations on the branch; the pins chosen are the ones chart/v1-2x-test already runs green with, so they are known to be both allowlisted and compatible with workflows of this vintage.

The "airflow-ctl 0.1.5: test to stable" sync (apache#67294) copied main's airflow-core/pyproject.toml metadata onto this branch without the matching sources. Three leftovers stayed behind: - the distribution version became 3.3.0 while airflow-core/src/airflow/__init__.py stayed 3.2.1 - the Task SDK requirement became >=1.3.0,<1.4.0 while task-sdk on this branch is 1.2.1 - a force-include and a shared_distributions entry appeared for apache-airflow-shared-state, which has no shared/state folder here Once CI actually started running on this branch, the CI image build failed pip check on the resulting triangle: apache-airflow 3.2.1 has requirement apache-airflow-core==3.2.1, but you have apache-airflow-core 3.3.0 apache-airflow-core 3.3.0 has requirement apache-airflow-task-sdk<1.4.0,>=1.3.0, but you have 1.2.1 apache-airflow-task-sdk 1.2.1 has requirement apache-airflow-core<3.3.0,>=3.2.0, but you have 3.3.0 Realign the metadata with the sources that are on the branch, which is what check-version-consistency and check-shared-distributions-usage already expect, and refresh uv.lock, which had drifted from the same sync.

The same test-to-stable sync (apache#67294) repointed the mypy-airflow-ctl hook at ../scripts/ci/prek/run_mypy_full_dist_local_venv_or_breeze_in_ci.py, which only exists on main. On this branch prek dies before mypy runs: error: Failed to run hook `mypy-airflow-ctl` caused by: Run command `python hook` failed caused by: No such file or directory (os error 2) Point it back at mypy_local_folder.py, which is what airflow-core, task-sdk, devel-common and dev/scripts all use on this branch.

The test-to-stable sync (apache#67294) copied airflowctl's generated datamodels from main, so they describe Airflow 3.3's API while this branch ships core 3.2.1. Two consequences, both red once CI started running here: - generate-airflowctl-datamodels regenerates from ../airflow-core/src/airflow/api_fastapi and fails on any drift, so Static checks could never pass - the models required is_backfillable and timetable_periodic, which apache#64644 added in 3.3.0, so every single-object Dag response failed validation against this branch's own PROD image: ValidationError: 2 validation errors for DAGResponse is_backfillable Field required timetable_periodic Field required Run the hook to bring the models back in line with the spec on this branch. This drops 14 model classes that no airflowctl code or test references, plus the 3.3-only fields above. Note RELEASE_NOTES.rst credits "Add ``is_backfillable`` property to DAG API responses (apache#64644)" to airflowctl 0.1.5, but apache#64644 touches only airflow-core -- that line is sync noise, not a client feature.

Lee-W · 2026-08-05T09:39:40Z

since this PR only turn on the CI check and the fix should first be merged into v0-1-test and then back to v0-1-stable. the fix is now in v0-1-test. I'll merge this one now. and the ci will be green once we do another ctl release

Lee-W · 2026-07-30T08:51:34Z

Pull requests targeting this branch receive no CI at all today: the
airflow-ctl/ release-branch patterns are missing from this branch's workflow
trigger filters, so only branch-independent bot checks report and a PR can show
all-green without any tests or CodeQL ever running.

GitHub resolves trigger filters from the workflow files on the target branch,
so the equivalent fix on main (#69626) is a no-op here and has to land on the
release branch itself.

Same change as the companion PR against airflow-ctl/v0-1-test (#70724).

related: #69626

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

Pull requests targeting this branch received no CI at all: the airflow-ctl release-branch patterns were missing from the workflow trigger filters, so only branch-independent bot checks reported and a PR could show all-green without any tests or CodeQL ever running. GitHub resolves trigger filters from the workflow files on the target branch, so the equivalent fix on main (apache#69626) does not apply here and has to land on the release branch itself.

The ASF organisation-level Actions allowlist no longer permits the af78098f (v3.0.1) pin, and GitHub blocks the entire workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all and asf-allowlist-check reports the pin directly. v3.0.3 is already allowlisted and in use on chart/v1-2x-test, and stays within the same major version so the step inputs are unchanged.

The ASF organisation-level Actions allowlist no longer permits the pins this branch carries for astral-sh/setup-uv and aws-actions/configure-aws-credentials, and GitHub blocks the whole workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all. These are the last two allowlist violations on the branch; the pins chosen are the ones chart/v1-2x-test already runs green with, so they are known to be both allowlisted and compatible with workflows of this vintage.

The "airflow-ctl 0.1.5: test to stable" sync (apache#67294) copied main's airflow-core/pyproject.toml metadata onto this branch without the matching sources. Three leftovers stayed behind: - the distribution version became 3.3.0 while airflow-core/src/airflow/__init__.py stayed 3.2.1 - the Task SDK requirement became >=1.3.0,<1.4.0 while task-sdk on this branch is 1.2.1 - a force-include and a shared_distributions entry appeared for apache-airflow-shared-state, which has no shared/state folder here Once CI actually started running on this branch, the CI image build failed pip check on the resulting triangle: apache-airflow 3.2.1 has requirement apache-airflow-core==3.2.1, but you have apache-airflow-core 3.3.0 apache-airflow-core 3.3.0 has requirement apache-airflow-task-sdk<1.4.0,>=1.3.0, but you have 1.2.1 apache-airflow-task-sdk 1.2.1 has requirement apache-airflow-core<3.3.0,>=3.2.0, but you have 3.3.0 Realign the metadata with the sources that are on the branch, which is what check-version-consistency and check-shared-distributions-usage already expect, and refresh uv.lock, which had drifted from the same sync.

The same test-to-stable sync (apache#67294) repointed the mypy-airflow-ctl hook at ../scripts/ci/prek/run_mypy_full_dist_local_venv_or_breeze_in_ci.py, which only exists on main. On this branch prek dies before mypy runs: error: Failed to run hook `mypy-airflow-ctl` caused by: Run command `python hook` failed caused by: No such file or directory (os error 2) Point it back at mypy_local_folder.py, which is what airflow-core, task-sdk, devel-common and dev/scripts all use on this branch.

The test-to-stable sync (apache#67294) copied airflowctl's generated datamodels from main, so they describe Airflow 3.3's API while this branch ships core 3.2.1. Two consequences, both red once CI started running here: - generate-airflowctl-datamodels regenerates from ../airflow-core/src/airflow/api_fastapi and fails on any drift, so Static checks could never pass - the models required is_backfillable and timetable_periodic, which apache#64644 added in 3.3.0, so every single-object Dag response failed validation against this branch's own PROD image: ValidationError: 2 validation errors for DAGResponse is_backfillable Field required timetable_periodic Field required Run the hook to bring the models back in line with the spec on this branch. This drops 14 model classes that no airflowctl code or test references, plus the 3.3-only fields above. Note RELEASE_NOTES.rst credits "Add ``is_backfillable`` property to DAG API responses (apache#64644)" to airflowctl 0.1.5, but apache#64644 touches only airflow-core -- that line is sync noise, not a client feature.

Lee-W · 2026-08-05T09:39:40Z

since this PR only turn on the CI check and the fix should first be merged into v0-1-test and then back to v0-1-stable. the fix is now in v0-1-test. I'll merge this one now. and the ci will be green once we do another ctl release

Lee-W · 2026-07-30T08:51:34Z

Pull requests targeting this branch receive no CI at all today: the
airflow-ctl/ release-branch patterns are missing from this branch's workflow
trigger filters, so only branch-independent bot checks report and a PR can show
all-green without any tests or CodeQL ever running.

GitHub resolves trigger filters from the workflow files on the target branch,
so the equivalent fix on main (#69626) is a no-op here and has to land on the
release branch itself.

Same change as the companion PR against airflow-ctl/v0-1-test (#70724).

related: #69626

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

Pull requests targeting this branch received no CI at all: the airflow-ctl release-branch patterns were missing from the workflow trigger filters, so only branch-independent bot checks reported and a PR could show all-green without any tests or CodeQL ever running. GitHub resolves trigger filters from the workflow files on the target branch, so the equivalent fix on main (apache#69626) does not apply here and has to land on the release branch itself.

The ASF organisation-level Actions allowlist no longer permits the af78098f (v3.0.1) pin, and GitHub blocks the entire workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all and asf-allowlist-check reports the pin directly. v3.0.3 is already allowlisted and in use on chart/v1-2x-test, and stays within the same major version so the step inputs are unchanged.

The ASF organisation-level Actions allowlist no longer permits the pins this branch carries for astral-sh/setup-uv and aws-actions/configure-aws-credentials, and GitHub blocks the whole workflow at startup rather than failing the single step, so the test pipeline on this branch cannot start at all. These are the last two allowlist violations on the branch; the pins chosen are the ones chart/v1-2x-test already runs green with, so they are known to be both allowlisted and compatible with workflows of this vintage.

The "airflow-ctl 0.1.5: test to stable" sync (apache#67294) copied main's airflow-core/pyproject.toml metadata onto this branch without the matching sources. Three leftovers stayed behind: - the distribution version became 3.3.0 while airflow-core/src/airflow/__init__.py stayed 3.2.1 - the Task SDK requirement became >=1.3.0,<1.4.0 while task-sdk on this branch is 1.2.1 - a force-include and a shared_distributions entry appeared for apache-airflow-shared-state, which has no shared/state folder here Once CI actually started running on this branch, the CI image build failed pip check on the resulting triangle: apache-airflow 3.2.1 has requirement apache-airflow-core==3.2.1, but you have apache-airflow-core 3.3.0 apache-airflow-core 3.3.0 has requirement apache-airflow-task-sdk<1.4.0,>=1.3.0, but you have 1.2.1 apache-airflow-task-sdk 1.2.1 has requirement apache-airflow-core<3.3.0,>=3.2.0, but you have 3.3.0 Realign the metadata with the sources that are on the branch, which is what check-version-consistency and check-shared-distributions-usage already expect, and refresh uv.lock, which had drifted from the same sync.

The same test-to-stable sync (apache#67294) repointed the mypy-airflow-ctl hook at ../scripts/ci/prek/run_mypy_full_dist_local_venv_or_breeze_in_ci.py, which only exists on main. On this branch prek dies before mypy runs: error: Failed to run hook `mypy-airflow-ctl` caused by: Run command `python hook` failed caused by: No such file or directory (os error 2) Point it back at mypy_local_folder.py, which is what airflow-core, task-sdk, devel-common and dev/scripts all use on this branch.

The test-to-stable sync (apache#67294) copied airflowctl's generated datamodels from main, so they describe Airflow 3.3's API while this branch ships core 3.2.1. Two consequences, both red once CI started running here: - generate-airflowctl-datamodels regenerates from ../airflow-core/src/airflow/api_fastapi and fails on any drift, so Static checks could never pass - the models required is_backfillable and timetable_periodic, which apache#64644 added in 3.3.0, so every single-object Dag response failed validation against this branch's own PROD image: ValidationError: 2 validation errors for DAGResponse is_backfillable Field required timetable_periodic Field required Run the hook to bring the models back in line with the spec on this branch. This drops 14 model classes that no airflowctl code or test references, plus the 3.3-only fields above. Note RELEASE_NOTES.rst credits "Add ``is_backfillable`` property to DAG API responses (apache#64644)" to airflowctl 0.1.5, but apache#64644 touches only airflow-core -- that line is sync noise, not a client feature.

Lee-W · 2026-08-05T09:39:40Z

since this PR only turn on the CI check and the fix should first be merged into v0-1-test and then back to v0-1-stable. the fix is now in v0-1-test. I'll merge this one now. and the ci will be green once we do another ctl release

Lee-W requested review from amoghrajesh, ashb, bugraoz93, gopidesupavan, jason810496, jscheffl, kaxil and potiuk as code owners July 30, 2026 08:51

boring-cyborgBot added the area:dev-tools label Jul 30, 2026

Lee-W marked this pull request as draft July 30, 2026 09:02

potiuk approved these changes Jul 30, 2026
View reviewed changes

Lee-W marked this pull request as ready for review July 31, 2026 05:33

kaxil approved these changes Jul 31, 2026
View reviewed changes

Lee-W requested a review from dheerajturaga as a code owner July 31, 2026 12:55

Lee-W merged commit 93fc24a into apache:airflow-ctl/v0-1-stableAug 5, 2026
108 of 109 checks passed

Lee-W deleted the ci-trigger-airflow-ctl-v0-1-stable branch August 5, 2026 09:39