Skip to content

Cleanup: Move remaining provider tests from airflow-core to support standalone uv sync #60770

Description

@MadhuTiwari-345

Apache Airflow version

3.1.6

If "Other Airflow 3 version" selected, which one?

main (development)


What happened?

As part of the Airflow 3.x development effort, the repository is transitioning toward a stricter separation between airflow-core and provider packages.

Running:

cd airflow-core
uv sync

successfully creates a minimal core-only environment.

However, running the test suite in this environment reveals failures because some tests located in airflow-core still import provider modules (e.g. airflow.providers.*). Since providers and their dependencies are not installed in a core-only setup, those tests fail.

There is an existing TODO in contributing-docs/07_local_virtualenv.rst noting that standalone core development is not fully supported until remaining provider-dependent tests are moved out of airflow-core.

The current state prevents developers from running the core test suite independently without installing all providers.


What you think should happen instead?

airflow-core should be fully testable in isolation.

Specifically:

  • All tests under airflow-core should depend only on core functionality.
  • Tests that require provider functionality should be moved to the appropriate providers/* directories.
  • After cleanup, developers should be able to:
cd airflow-core
uv sync
pytest

and have the full core test suite pass without installing provider packages.

This aligns with the architectural goal of strict separation between core and providers and improves developer experience by reducing setup complexity and dependency surface area.


How to reproduce

  1. Clone the current main branch of the Airflow repository.
  2. Navigate to the core directory:
cd airflow-core
  1. Synchronize the environment:
uv sync
  1. Run the test suite:
pytest

Observe: Some tests fail due to imports from airflow.providers.*, indicating that provider-dependent tests still exist in the core test suite.


Operating System

Linux / macOS


Versions of Apache Airflow Providers

Not applicable (core-only environment)


Deployment

Other


Anything else?

This task is part of the broader Airflow 3.x effort to enforce clean separation between core and providers.

This PR will:

  • Identify provider-dependent tests currently under airflow-core
  • Move them to the appropriate provider packages
  • Ensure airflow-core tests pass in a standalone core-only environment

Are you willing to submit PR?

  • Yes I am willing to submit a PR!

Activity

  1. boring-cyborg commented on Jan 19, 2026

    @boring-cyborg

    Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

  2. MadhuTiwari-345 commented on Jan 19, 2026

    @MadhuTiwari-345
    Author

    Thanks for the quick response! I’ll start investigating which remaining provider-dependent tests are still under airflow-core and propose a PR to move them into the appropriate provider packages.

  3. potiuk commented on Feb 14, 2026

    @potiuk
    Member

    BTW. The description is wrong. uv sync will not fail, but some tests will not succeed. You need to look at those failures and fix them.

  4. potiuk commented on Feb 14, 2026

    @potiuk
    Member

    Assigned you.

  5. MadhuTiwari-345 commented on Feb 14, 2026

    @MadhuTiwari-345
    Author

    Thanks for the clarification! @potiuk

    I’ll run UV sync again in airflow-core, execute the test suite, and identify which specific tests fail due to provider dependencies. I’ll then update the issue description to reflect that the problem is failing tests (not UV sync itself), and start moving the remaining provider-dependent tests to the appropriate provider packages.

    I’ll share findings once I’ve isolated the failures.

  6. potiuk commented on Mar 2, 2026

    @potiuk
    Member

    @MadhuTiwari-345 We are unassigning you from this issue as part of our updated assignment policy.

    This is not meant to discourage your contribution — quite the opposite! You are still very welcome to work on this issue and submit a PR for it. Simply comment that you are working on it and open a PR when ready.

    We found that formal assignments were not working well, as they often prevented others from contributing when the assignee was not actively working on the issue.

  7. MadhuTiwari-345 commented on Mar 3, 2026

    @MadhuTiwari-345
    Author

    @potiuk I had started working on this...I changed the description as you told me about the changes some days ago so accordingly I changed it

  8. shahar1 commented on Sep 13, 2026

    @shahar1
    Contributor

    Closing as it can be done without a tracking issue

  9. removed
    needs-triagelabel for new issues that we didn't triage yet
    on Sep 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions