* [main] CI: Upgrade important CI environment
* Ignore pydantic-ai's generic OpenAI-compatible provider in vendor drift checks
pydantic-ai-slim 2.63.0 adds a provider for any OpenAI-compatible endpoint. It needs a service name at construction and infer_model has no prefix for it, so a common.ai connection can never reach it and it is not a vendor the services page should list.
Generated-by: Claude Opus 5
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
* [main] CI: Upgrade important CI environment
* Bump pypdf to 6.21.4 to fix high-severity advisories
The CI environment upgrade resolved pypdf 6.21.3, which the dependency
review gate rejects (GHSA-mfr5-77xh-9j7h, GHSA-cggf-277g-3q54,
GHSA-5849-834g-hvw5). The fixed 6.21.4 is still inside the 4-day
exclude-newer window, so add a temporary per-package cutoff for it.
Generated-by: Claude Opus 5
* Support pydantic-ai 2.60+ and opensandbox 1.2 in common.ai provider
pydantic-ai 2.60 records a durable streamed model request as the bare
response rather than a response-plus-events wrapper, so replaying or
tracking a streamed request in AirflowDurability failed to decode it.
The same release answers a tool retry with the call's own ToolReturnPart
(outcome "retried") instead of RetryPromptPart, which broke tests that
told retries from results by part type.
opensandbox 1.2 allows an egress rule with ports and no target. When the
enforced policy did not match the requested one, sorting the allowed
targets for the error message raised TypeError on that None, hiding the
real reason the sandbox was refused.
Both work with the older releases too, which the provider still supports.
Generated-by: Claude Opus 5
* Fix provider tests and type checks after the dependency upgrade
The tool-part predicates in the common.ai tests returned a plain bool, so
mypy could not narrow the message part they matched and the providers
type check failed.
On Python 3.14 the upgrade moves snowflake-connector-python to 5.1 and
snowflake-sqlalchemy to 2.1. connector 5.1's connect() no longer goes
through SnowflakeConnection, so patching that class stopped intercepting
the connection and the test tried a real login. snowflake-sqlalchemy
2.0.0 started percent-encoding "?" in the URL password, which the URI
test pinned to the older, unencoded form. Older Python versions keep the
earlier releases, so both tests have to accept either.
Generated-by: Claude Opus 5
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
Previously to see the same error in docs build as you would get in CI,
you would have to run both the docs build and the spellchecking build.
The issue was that the spellcheck (using sphinx-contrib's spelling) was
defined as a new builder, meaning you could either build HTML, or you
can check spelling. On CI, this didn't result in any extra wall-clock
time as the jobs were parallelized (but this change does remove a job
from the overall matrix), but locally that was almost always not the
case, so this would mean full build to view the HTML, and spell checking
build to look for errors, resulting in it taking twice as long.
The upstream spellchecker was also slower than it should be mainly
because its importable-module filter calls find_spec on every distinct
identifier-like word before consulting the dictionary. Here it runs only
for words that are still misspelled. Word lists, filters and
`:spelling:ignore:` behave as before.
This also handles errors a lot more nicely (hence all the code deletions):
- They are written natively to a JSON file, not scraped from a stream
- They also show up as GH annotations (Where we can attribute it to a
real file) to make fixing them easier on PRs.
Please note: this is lightly breaking for Airflow contributors as
`breeze build-docs --docs-only` and `--spellcheck-only` are gone --
every build checks spelling now as it is essentially free (on the order
of milliseconds per module).
* Update docs for the Python 3.11 baseline
Contributing docs, Breeze docs, Docker stack docs and the user-facing
installation pages used Python 3.10 as the example and default
version. Examples and defaults now use 3.11; historical changelog
entries and ADRs keep their original wording.
* Re-pad the image naming table after dropping Python 3.10
* Fix stale Python 3.10 examples left in the Python 3.11 docs update
Review found commands that still pin a 3.10.x interpreter, which can no
longer install Breeze or Airflow, shell prompts and pytest transcripts
that still show 3.10, and a note that tied the supported Python range to
Airflow 3.2.0 even though the 3.2 to 3.4 release lines still accept 3.10.
Two Breeze examples used options that do not exist. The python-client
release notes presented `breeze --python 3.11` as equivalent to
`UV_PYTHON=3.11`, but the reproducibility guard checks the interpreter
Breeze itself runs on, so only the `UV_PYTHON` form works. The Docker
stack build examples now refer to the default Python version instead of
a hard-coded one, so they stop drifting with every bump.
* Fix remaining Python 3.10 references in docs and image examples
Review found more shell prompts that still show a 3.10 Breeze image.
The air-gapped image example pinned Airflow 2.5.3, which publishes no
3.11 constraints, so its download step fetched a 404 page and failed;
it also used extras that Airflow 3 no longer defines. The contributor
quick start called 3.10 end-of-life before its October 2026 end-of-life
date.
* Update Python version in database setup guide
Updated Python version in setup instructions from 3.8.10 to 3.11.16.
* Fix stale Python 3.10 constraints examples in INSTALL
Generated-by: Claude Opus 5
---------
Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
* Require Python 3.11 in all distributions
Every pyproject.toml that declares requires-python now says >= 3.11 and
drops the Python 3.10 trove classifier, the tomli build requirement that
only existed for 3.10 and the per-version dependency markers for 3.10.
Lock files are regenerated.
With 3.10 gone, the tomli fallbacks in scripts, dev tooling and tests go
too, along with the tomli additional_dependencies of the prek hooks and
the blacken-docs py310 target. The tomllib imports that only sat inside
functions because of the fallback move to the top of their modules. The
four dev/registry and scripts/ci/prek modules left out of the earlier
UP017 pass also take their timezone.utc to datetime.UTC fixes here. The
minimum host Python checked by check-min-python-version, the default
Python of run_generate_constraints.py and the provider cut-off date
parsing (fromisoformat, which reads a trailing Z from 3.11) follow the
new baseline.
ruff infers py311 from the new requires-python, which enables the
PEP 646 star-index fix (UP044) applied here and makes two more rules
reportable: UP042 (str, Enum to StrEnum) alters what str() and
format() return for serialized enum values, and ASYNC109 means
dropping the public timeout parameter from async APIs. Both need
per-site judgement, so they go on the ignore list with that rationale.
The datamodel-codegen target moves to 3.11 too, with use-specialized-enum
turned off for the same reason: otherwise the generated Task SDK and
airflowctl enums would switch from (str, Enum) to StrEnum.
* Drop the Python 3.10 provider metadata shim
With provider distributions now requiring Python 3.11, breeze can derive
requires-python and classifiers from the default and allowed versions
again. The patch-exclusion test and the matching example in
MANAGING_PROVIDERS_LIFECYCLE.rst move from 3.10.0 to 3.11.0, the oldest
patch release CI still covers.
* Keep Breeze's locked dependency versions when dropping Python 3.10
Relocking Breeze for the Python 3.11 baseline ran while recently bumped versions were still inside the 4-day exclude-newer window, so it downgraded pyjwt (reverting #73969), prek, boto3/botocore and filelock. Relocking from the previous lock keeps them and only drops the packages Python 3.11 no longer needs.
Generated-by: Claude Opus 5
---------
Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
* [main] CI: Upgrade important CI environment
* Cap azure-datalake-store below 1 in the Microsoft Azure provider
azure-datalake-store 1.x removed the lib.auth API that AzureDataLakeHook
uses, so the floor bump to 1.0.1 in the CI upgrade broke the hook and
every TestAzureDataLakeHook test. Supporting 1.x is tracked in #73795.
Generated-by: Claude Opus 5
* Regenerate provider requirement tables after the floor bumps
The floor bumps changed provider pyproject.toml files without regenerating
the README.rst and docs/index.rst requirement tables derived from them,
so update-providers-build-files and sync-provider-readme failed static checks.
Generated-by: Claude Opus 5
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
This reverts commit ecfa20322b.
Main is broken, so reverting this for now.
Errors:
```
azure-ai-projects 2.7.0 has requirement openai>=3.0.0, but you have openai 2.54.0.
```
* Move SendGrid and SES email backend setup docs to their providers
The core email-config how-to mixed general Airflow email configuration
(SMTP, templates, from_email) with full provider-specific setup guides
for SendGrid and Amazon SES, duplicating information that already
belongs with each provider and making the core doc harder to navigate.
Move the provider-specific instructions into a new email-backend page
in each provider's docs, link back to the core doc for the shared
concepts, and have the core doc simply present the email_backend
mechanism with links out to the providers. Also add the missing
:ref: cross-link in the SES emailer docstring, mirroring the one
SendGrid's emailer already had.
* Auto-generate the list of email backends from provider metadata
* fix
* fix
* Validate provider metadata list entries instead of ignoring them
The items blocks for queues, plugins and task-decorators listed their field
names directly under items, where they are not JSON Schema keywords, so the
blocks were inert and any shape passed. A provider author following what those
blocks appeared to document — a dict for queues, or a path key for a decorator
— got no error and was quietly dropped by the consumers instead. Pinning each
section to the shape the provider.yaml files and generated payloads actually
use turns that into a failure at authoring time. The custom-provider howto
named the same nonexistent path field.
Raised in review of #70190.
* Keep runtime provider metadata validation permissive
The runtime schema is documented as deliberately looser than the development
one, and its validate() call is unwrapped in provider discovery, so a single
installed provider emitting an outdated entry shape would abort discovery for
every provider in that process instead of costing just that entry a logged
warning. The structural descriptions stay behind so the schema no longer
documents a shape it never actually enforced.
* Reject unknown keys in provider.yaml decorator and plugin entries
Requiring the right keys does not stop a leftover one sitting beside them, so a
stale `path:` next to a correct `class-name:` still validated — exactly the
confusion this branch set out to remove. Every sibling item block in this
authoring schema already closes itself off this way.
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.
General-purpose LLM operator and TaskFlow decorator for prompt-based
tasks (summarization, extraction, classification, structured output).
The operator wraps PydanticAIHook.create_agent() with support for
structured output via Pydantic BaseModel and pass-through agent_params
for pydantic-ai Agent configuration (retries, model_settings, tools).
Adds the "ai" tag to provider.yaml.schema.json for docs grouping.
Co-authored-by: GPK <gopidesupavan@gmail.com>
* Fix mypy and provider.yaml validation CI failures
- Add type annotation for `agent` variable (mypy var-annotated)
- Add `how-to-guide` to provider.yaml for llm.rst doc
* Add 'llm' to spelling wordlist
Auto-generated doc index files for example DAGs contain 'llm' in
plain text where backtick quoting is not possible.
---------
Co-authored-by: GPK <gopidesupavan@gmail.com>
* 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>
* Initial plan
* Add CLI section to provider system - schema and core implementation
Co-authored-by: jason810496 <68415893+jason810496@users.noreply.github.com>
* Add CLI functions for Keycloak and Amazon auth managers
Co-authored-by: jason810496 <68415893+jason810496@users.noreply.github.com>
* Simplify CLI schema and move functions to definition.py
- Change CLI schema from object with 'function' property to simple string array
- Update ProvidersManager to parse CLI items as strings directly
- Move get_xxx_cli_commands functions from __init__.py to definition.py
- Update all provider.yaml files to use simplified format: `cli: [path.to.function]`
Co-authored-by: jason810496 <68415893+jason810496@users.noreply.github.com>
* Add CLI latency benchmark script
* Final refactor for ProviderManager
* Add CLI command definitions to provider info for Amazon, Fab, and Keycloak
* Refactor CLI commands for Celery executor and add provider info section
* Refactor Kubernetes CLI integration and add provider info section
* Add CLI commands for Edge Worker and integrate provider info retrieval
* Fix CLI command definitions for Celery and Kubernetes providers
* Fix static check
* Refactor CLI tests with ProviderManger instead of AuthManger +
ExecutorLoader
* Add unit tests for Celery, Kubernetes, and Edge CLI command definitions
* Fix k8s, edge compat test
Fix conf_vars import in keycloak
* Move cli_commands.definition to cli.definition for FAB
Fix FAB get_provider_info
* Add prek check to avoid import heavy module in cli.definition
* Remove auth_manager prefix for CLI definition for AWS, FAB, and Keycloak
* Doc: Add CLI commands directive and template for provider-level CLI commands
* Doc: Move generate doc get_parser to .cli.definition for each provider
- also unifiy the the provider CLI doc as cli-ref.rst
* Doc: mention provider-level CLI in airflow-core doc
* Doc: add CLI section to provider documentation and clarify CLI command usage
* Improve cli_parser speed by skipping _correctness_check for AuthManager
and Executor
Refactor ProvidersManager to consolidate executor and auth manager tracking without correctness checks
* Fix mypy error and import for test
* Enhance CLI warnings for missing 'cli' sections in provider info for executors and auth managers
* Fix tests
* Fix list has no add attribute error
Fix auth manager unused assign
* Refactor skip_cli_test function to simplify logic and remove unnecessary condition for Airflow 3.2+
Try fix provider cli test
Refactor CLI test skipping logic for Airflow version compatibility
* Finialize compatibility test
Fix parser attribute not found
Fix executors test error
Fix exeuctors compat test
Fix compat test for k8s cli
* Add test for ProviderManager change
* fixup! Remove unused __future__.annotations
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
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 !=.
This PR addresses the case where we have to manage dependencies
between Airfow distributions and we have to manage the right lower
bind versions for them.
Since we missed a comprehensive documentation on how our dependencies
are managed in general, and we had no good place to describe it, this
PR not only adds code to manage it, but also extends the documentation
of the "12_airflw_dependencies_and_extras.rst" chapter of the
contributing documentation to include comprehensive (but also hopefully
helpful) documentation explaining to contributors how our dependencies
are managed.
The changes in the doc:
* add missing documentation explaining dependency management in airflow
distributions in the monorepo
* adds selective check to verify if cross-airflow-distribution
dependencies have not been modified in the PR, and fails if they were,
unless appropriate label is set on the PR
* adds breeze tests covering the test cases of selective check
After adding -source package with release date to providers release,
we also need to update the source download documentation to link to
the right source tarball.
This PR adds the last missing bits and pieces to do that:
1) Updates information about format of RELEASE_DATE and supported
(potentially) YYYY_MM_DD_NN format
2) The release date parameter is used and verified at release
docuemntation preparation time and it's stored in
"providers/.last_release_date.txt"
3) The relase date of the current release (stored in the commit
which is used to release providers) is used to produce the
right links - both in "providers summary" and in individual
provider's package documntation
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
* Breeze changes for Python 3.13
* Pyproject.toml provider changes for Python 3.13
* README.rst changes for providers for Python 3.13
* Add Python 3.13 support for Airflow.
Added Python 3.13 support across the codebase, including:
* CI/CD workflow updates to handle Python 3.13.
* Dockerfile and environment variable adjustments for compatibility.
* Documentation updates to list Python 3.13 as supported.
* Dependency and code changes for compatibility with new/changed
libraries (e.g., numpy 2.x, greenlet, pendulum).
* Test and plugin manager adjustments for Python 3.13-specific behaviors.
* Removal or skipping of tests and features not compatible with Python 3.13.
* Improved error handling and logging for unsupported plugins/providers
on Python 3.13.
* Updated all provider README.rst files to:
* List Python 3.13 as a supported version.
* Adjust dependency requirements for Python 3.13 (e.g., pandas,
pyarrow, ray, etc.).
* Add or update notes about excluded or conditionally supported
dependencies for Python 3.13.
* Document any known incompatibilities or workarounds for specific
providers.
* Updated all provider pyproject.toml files and automation to:
* Add Python 3.13 to the supported classifiers.
* Adjust requires-python and dependency constraints for Python 3.13.
* Exclude Python 3.13 for providers that are not yet compatible (e.g.,
those depending on Flask AppBuilder).
* Add conditional dependencies for new versions of libraries required
by Python 3.13.
* Updated Breeze and related scripts to:
* Build and test with Python 3.13.
* Update documentation and release scripts to include Python 3.13.
* Ensure all dev tooling and test environments work with Python 3.13.
* Removed remaining FAB related code from core and removed tests for
older FAB provider versions (<1.3.0)
* some of the tests in core still depend on FAB - but we make them
optional - both for parsing (we need to skip some imports) and
execution - because they test a legacy behaviour of embedding
Flask plugins that is still supported in core.
* k8s tests now run also with SimpleAuthManager and SimpleAuthManager
is used automatically when runnin tests in Python 3.13
* migration tests had to be excluded fo Python 3.13 because we cannot
migrate down on Python 3.13 without FAB tables created. The tests
will be brought back when FAB is supported or when we release 3.1
and start working on 3.2, we should be able to migrate down to 3.1
* Weaviate tests have been updated to handle case where weaviate-client
is > 2.10.0 - because it started to use httpx instead of requests,
and Python 3.13 actually unblocks using older version of weaviate
(it was previously blocked indirectly via Flask dependencies and
grpcio).
* Added doc change in our rules on what is the "default" Python version
for airflow images - handling the case where we cannot use "newest"
Python version as default where not all "regular" image providers are
supported in the latest version
* Connection is now flushed in `configure_git_connection_for_dag_bundle`
just before `clear_db_connections` - in order to handle Python 3.13
case where FAB app is not initialized by other fixtures - performing
implicit flush along the way
* Cleaning db connections was added to test_dag_run and test_dags test
in fast_api as the test implicitly rely on having connections
cleared (no test git connections added) - this will make the tests
side-effect free.
* Conditionally skipping some serialization tests involving yandex
and ray on Python 3.13 until they support Python 3.13
Follow up after #52967 -> from later discussions it turned out that
it's not really the ~= that is wrong and ambiguous, but that just
upper-binding of Python version is generally considered as a bad
idea - and it's not Astral's view but it's general consensus that
upper-binding of "python-requires" is bad. Since ~= implies
upper-binding, simply replacing it with >= is likely the best option
we can choose.
The common.messaging abstraction should discover common messaging
queue providers using the same mechanism as we have for other core
extensions. Previously common.messaging had the optional (but not
really) dependencies to other providers, but that was not needed
and introduced unnecessary coupling.
By switching to our built-in discovery mechanism we get immediately
all the niceties of provider discovery mechanisms:
* queue is provided by the actual provider where the service or
integration already is implemented (sqs -> amazon provider, in
the future kafka -> kafka provider)
* queues are discovered from installed providers
* there is no coupling or imports between common.messaging and the
providers that implement messaging, the dependency is in the other
way - providers that implement messaging depend on common.messaging
* airflow providers queues CLI and providers core extensions
documentation is automatically generated
* Add back missing `[sources]` link in generated documentation's includes
The exampleinclude of ours used to have generated "sources" link to link
to sources of the examples. This was however gone after recent doc
build refactoring.
The problem was the example directive include import and lack of
tests folder available on the python path. Both issues fixed in this
PR.
Fixes: #49893
* fixup! Add back missing `[sources]` link in generated documentation's includes
After moving the docs, the links to "Suggest a change" for airflow,
docker-compose and helm-chart lead to a wrong URL. This PR fixes it.
We also do not use analytics any more so configuration for it is not
needed any more.
Fixes: #49694
github-actions[bot]andJarek Potiuk
Ash Berlin-Taylor
Shahar EpsteinandJarek Potiuk
Elad Kalif
Wei Lee
Jens Scheffler
Jason(Zhe-You) Liu
Wei Lee
Dev-iLandClaude Opus 4.6
Kaxil NaikandGPK
fritz-astronomer
Dev-iLandCopilot
Vincent
Amogh Desai
Kalyan R