Record in the 'Changes after publishing the images' table that the 3.3.0 Python 3.11/3.12 images had their downgraded databricks stack corrected (provider 6.13.0 -> 7.16.1, connector 2.0.2 -> 4.2.5, thrift 0.23.0 -> 0.16.0).
related: #69603
#65374 added opensearch to prod_image_installed_providers.txt (so the PROD
image verify asserts it is installed) but did not add it to the default
image extras. opensearch is therefore the only required provider that is
neither a default extra nor a bundled core dependency, so its only path
into the image was being built from source.
On a release branch the source build skips already-released providers
(the final tag providers-opensearch/<v> exists), so opensearch is the
single required provider with no fallback and the PROD image verify
(test_required_providers_are_installed) fails. main passes only because
its dev-mode build compiles every provider from source in-place.
Add opensearch to the default extras so it is backfilled from PyPI the
same way every other required provider is, making the PROD image
consistent across dev and release builds.
* Sync default image Python version references
* Fix mypy type error in _read_global_constants_assignment return type
Since ast.literal_eval() returns Any, annotating the private helper as
returning str | list[str] caused mypy errors in both callers: assigning
the result to `list[str]` and returning it as `str`. Changing the return
type to Any (which matches ast.literal_eval) resolves both without
requiring casts.
* Update scripts/ci/prek/common_prek_utils.py
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Set `exclude-newer = "4 days"` in `[tool.uv]` to only consider package
versions uploaded at least 4 days ago. This provides supply-chain security
by giving the community time to identify and remediate compromised releases.
Also downgrade pyodps requirement for Python >= 3.13 from >=0.12.6 to
>=0.12.5.1 since 0.12.6 was published within the cooldown window.
* Update python version exclusion to 3.15
* Add 3.14 metadata version classifiers and related constants
* Regenerate Breeze command help screenshots
* Assorted workarounds to fix breeze image building
- constraints are skipped entirely
- greenlet pin updated
* Exclude cassandra
* Exclude amazon
* Exclude google
* CI: Only add pydantic extra to Airflow 2 migration tests
Before this fix there were two separate issues in the migration-test setup for Python 3.14:
1. The migration workflow always passes --airflow-extras pydantic.
2. For Python 3.14, the minimum Airflow version is resolved to 3.2.0 by get_min_airflow_version_for_python.py, and apache-airflow[pydantic]==3.2.0 is not a valid thing to install.
So when constraints installation fails, the fallback path tries to install an invalid spec.
* Disable DB migration tests for python 3.14
* Enforce werkzeug 3.x for python 3.14
* Increase K8s executor test timeout for Python 3.14
Python 3.14 changed the default multiprocessing start method from 'fork' to 'forkserver' on Linux. The forkserver start method is slower because each new process must import modules from scratch rather than copying the parent's address space. This makes `multiprocessing.Manager()` initialization take longer, causing the test to exceed its 10s timeout.
* Adapt LocalExecutor tests for Python 3.14 forkserver default
Python 3.14 changed the default multiprocessing start method from
'fork' to 'forkserver' on Linux. Like 'spawn', 'forkserver' doesn't
share the parent's address space, so mock patches applied in the test
process are invisible to worker subprocesses.
- Skip tests that mock across process boundaries on non-fork methods
- Add test_executor_lazy_worker_spawning to verify that non-fork start
methods defer worker creation and skip gc.freeze
- Make test_multiple_team_executors_isolation and
test_global_executor_without_team_name assert the correct worker
count for each start method instead of assuming pre-spawning
- Remove skip from test_clean_stop_on_signal (works on all methods)
and increase timeout from 5s to 30s for forkserver overhead
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Bump dependencies to versions supporting 3.14
* Fix PROD image build failing on Python 3.14 due to excluded providers
The PROD image build installed all provider wheels regardless of Python
version compatibility. Providers like google and amazon that exclude
Python 3.14 were still passed to pip, causing resolution failures (e.g.
ray has no cp314 wheel on PyPI).
Two fixes:
- get_distribution_specs.py now reads each wheel's Requires-Python
metadata and skips incompatible wheels instead of passing them to pip.
- The requires-python specifier generation used !=3.14 which per PEP 440
only excludes 3.14.0, not 3.14.3. Changed to !=3.14.* wildcard.
* Split core test types into 2 matrix groups to avoid OOM on Python 3.14
Non-DB core tests use xdist which runs all test types in a single pytest
process. With 2059 items across 4 workers, memory accumulates until the
OOM killer strikes at ~86% completion (exit code 137).
Split core test types into 2 groups (API/Always/CLI and
Core/Other/Serialization), similar to how provider tests already use
_split_list with NUMBER_OF_LOW_DEP_SLICES. Each group gets ~1000 items,
well under the ~1770 threshold where OOM occurs.
Update selective_checks test expectations to reflect the 2-group split.
* Gracefully handle an already removed password file in fixture
The old code had a check-then-act race (if `os.path.exists` → `os.remove`), which fails when the file doesn't exist at removal time. `contextlib.suppress(FileNotFoundError)` handles this atomically — if the file is missing (never created in this xdist worker, or removed between check and delete), it's silently ignored.
* Fix OOM and flaky tests in test_process_utils
Replace multiprocessing.Process with subprocess.Popen running minimal
inline scripts. multiprocessing.Process uses fork(), which duplicates
the entire xdist worker memory. At 95% test completion the worker has
accumulated hundreds of MBs; forking it triggers the OOM killer
(exit code 137) on Python 3.14.
subprocess.Popen starts a fresh lightweight process (~10MB) without
copying the parent's memory, avoiding the OOM entirely.
Also replace the racy ps -ax process counting in
TestKillChildProcessesByPids with psutil.pid_exists() checks on the
specific PID — the old approach was non-deterministic because unrelated
processes could start/stop between measurements.
* Add prek hook to validate python_version markers for excluded providers
When a provider declares excluded-python-versions in provider.yaml,
every dependency string referencing that provider in pyproject.toml
must carry a matching python_version marker. Missing markers cause
excluded providers to be silently installed as transitive dependencies
(e.g. aiobotocore pulling in amazon on Python 3.14).
The new check-excluded-provider-markers hook reads exclusions from
provider.yaml and validates all dependency strings in pyproject.toml
at commit time, preventing regressions like the one fixed in the
previous commit.
* Update `uv.lock`
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
IntelliJ IDEA .iml files could end up in sdist/wheel packages when
building distributions that lack their own .gitignore. Adding *.iml
to every distribution's .gitignore ensures these IDE metadata files
are excluded from built packages.
* Fix all build-system/requires including transitive dependencies
Add a feature to fix all build-system/requires to make build
reproducibility works. The build-system requires are managed
automatically by the `upgrade-important-versions` prek hook.
This should not only provide reproducibility, but also it should
prevent cases where transient dependency upgrade might break
building sdist (for example as it happened with virtualenv 21
breaking hatchling with https://github.com/pypa/hatch/issues/2193
* Fix mypy 'Cannot infer type of lambda' error in upgrade script
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* Remove `UV_HTTP_TIMEOUT`
See https://github.com/apache/airflow/discussions/61205.
Airflow is a large, popular project and a reference for other projects. I'd like to remove the historic use of `UV_HTTP_TIMEOUT`, that isn't required today anymore with the changes in uv. This will also benefit airflow, as broken network connections will fail much faster (either triggering a retry quicker, or reporting to the user in less than 4 x 300s = 20min)
I've kept the CLI option in the dev script to not break existing invocations, I can also remove it if you think it's safe
* Remove `--uv-http-timeout` from launchers too
While we have some discussion on-going whether we should use some
shorter, machine-readable friendly versions of licence specification
in our source code headers here [1], the notion is that:
a) PMC can make judgment calls when to include different versions of
the licence
b) This expectation only applies to the code we actually release
in our official releases.
This change makes some judgment call on using much shorter, SPDX
driven licence headers in some specific files:
* markdown files that are intended to be consumed by agents
(AGENTS.md, SKILLS.md, CLAUDE.md and so on)
* all the markdown .github/* files that are clearly meta-data for
GitHub and which we exclude from released sources
We also make sure all those files are excluded from the official
source releases and distribution packages we prepare.
[1] https://lists.apache.org/thread/j1tn63r2lf13v3d1tnnqff8fkcl4nx53
* Add description on how 3rd-party dependency security issues are handled
Our users seem to not have a good idea on how 3rd-party dependencies
are handled and how they should approach it and open issues that are
often closed and we need to explain them what is expected of them -
they have pretty unrealistic expecations that every single CVE in
every single dependency will be addressed when they open an issue.
This description clarifies how handling of 3rd-party dependency
issues should be done and what are responsibilities and expectations
of the users, and what they can expect from the maintainers.
This will help us to direct such users to this process without
spending our time on explaining it over and over again.
Apply suggestions from code review
Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
* Update airflow-core/docs/security/vulnerabilities-in-3rd-party-dependencies.rst
Co-authored-by: Shahar Epstein <60007259+shahar1@users.noreply.github.com>
* Update airflow-core/docs/security/vulnerabilities-in-3rd-party-dependencies.rst
Co-authored-by: Amogh Desai <amoghrajesh1999@gmail.com>
---------
Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
Co-authored-by: Shahar Epstein <60007259+shahar1@users.noreply.github.com>
Co-authored-by: Amogh Desai <amoghrajesh1999@gmail.com>
With .pyc files removal after compilation we save very little
space. Uncompressed sizes of regular airflow image are:
Before 7.63GB
After 7.66GB
So we have images bigger by < 0.5%
And it seems that long running containers without those files can
suffer from continuous attempts to recreate the .pyc files that
fail due to lack of permissions and cause negative dentries to
be continuously created:
https://lwn.net/Articles/814535/
Those negative dentries are created by kernel - caching the fact
that a file was not available - which speeds up lookup but also
takes a bit of memory. It seems that when compiled Python has
the .pyc files removed, it tries to recreate them with timestamped
entries every time new interpreter is started.
While this is not a problem for long running processes - because
those interpreters are run exactly once per container, this is
a problem if you use `exec` in containers to run Health Checks.
Evey health-check creates a new interpreter and every time it is
created, a new negative dentries to take kernel memory.
By not removing the .pyc files we increase a bit the size of the
image but improve a little the startup time (no need to compile
Python internal .py files, as well as get rid of the negative
dentries problem.
This PR likely:
Fixes: #58509Fixes: #42195
* feat: add PYTHON_LTO build arg for FIPS compliance
* Fix static checks and add newsfragment for FIPS support
* docs: add comprehensive LTO-FIPS documentation with MD5 explanation
* docs: add FIPS compliance documentation and note about other potential incompatibilities
* Fix spelling and update Dockerfiles
* Fix formatting errors via pre-commit
Since UV and other installers essentially ignore < limit in the
python-requires, a good practice is to simply exclude current Python
versions that we **know** we are not compatible with rather than
using <.
Python 3.14 is a thing now and people will get it by default as
latest versions, but we do not run our tests with Python 3.14
yet (not until March/April 2026). Providers have all
upper-bind exclusion except those that do not support Python 3.13,
but that's ok because they are actually limited by Airflow they
can be installed on. But for distributions like airflow-ctl,
we should explicitly exclude 3.14 until we support and test it.
This PR synchronizes all python-requires in non-provider
distribution to consistently exclude Python 3.14 with !=.
According to https://www.apache.org/legal/src-headers.html#faq-binaries
all our released source packages and binaries should have both LICENCE
and NOTICE files - even if we do not have any 3rd-party software embedded.
This PR updates it accross the board and makes sure that all our
distributions contain both LICENCE and NOTICE file and that they
are added as "licence" information to all our distribution packages
when they are built.
This PR also modernizes all our pyproject.toml files with regards
to latest metadata for licenses:
* license-file is an array of glob patterns
* license is s license expression
* the deprecated Trove Classifier is removed
Inspired by #58131
As discussed in https://lists.apache.org/thread/cwfmqbzxsm0gobtpo8kmfr99nfv29c2y
we are temporarily (or not) removing MySQL client support from Airflow
container images in order to stop our CI canary builds from failing.
If consensus or vote will be reached to remove it, we will leave it as
is, if we will find other ways how to keep mysql client support, we
will revert that change and restore MySQL client support.
* fix(docker): prevent airflow-init from failing after db migrate where no command is passed-in
* docs(docker-stack-docs/entrypoint.rst): container clean exit behavior with _AIRFLOW_DB_MIGRATE and no command
* chore: update inlined Dockerfile after entrypoint.sh script change
---------
Co-authored-by: Roy M. <roy.ma9@gmail.com>
After migrating to python built from sources, it turned out that we
had a weird mixture of system and source build python in our CI images
images. There were some dependencies installed that installed
python3 debian dependencies and they were breaking the way how source
build python 3.11 interacted with system one. Namely - debian Python 3.11
had internal ABI incompatibility between 3.11.4 and 3.11.5 that caused
the ssl build with latest 3.11.5 fail when 3.11.5 system python has been
installed while the new python was being built - because system includes
interfered with the build process.
The system python was pulled by "software-properties-common" and "gdb" -
we do not need to use either of them during the build process, and user
in
In order to avoid this, we now make sure that we do not install any
debian dependencies that pull any of the python3 system packages, before
we install Python from sources.
We also reviewed and cleaned the way how we configure list of packages
installed during image building:
* packages are reviewed and unnecessary ones removed
* packages that are pulling python3 system packages are moved to
additional apt dev dependencies
* additional apt dev dependencies are installed AFTER python is
installed
* the packages listed in scripts are now one-per-line
* they are alphabetically sorted
* finally LD_LIBRARY_PATH is set to have the "source-installed"
python libraries to be always prioritised against the system
libraries if system libraries are installed to the main "/usr/lib"
directories.
github-actions[bot]andJarek Potiuk
bujjibabukatta
Arkadiusz Bach
Andrew Chang
Rahul Vats
Jens Scheffler
Christos Bisias
DaveT1991andCopilot
Jason(Zhe-You) Liu
Wei Lee
Dev-iL
konsti
Srabasti Banerjee
Guan-Ming (Wesley) Chiu
shubhamkotiandShubham Koti
Brandon Kaplan
Subham
Creative AtaraxiaandRoy M.
Kaxil Naik
GPK