@wumiro - I suggest to not create those as draft unless you know it's not ready for review. Most of us will not even look at PRs that are in Draft state. Those changes look like ready for review (but because they are Draft it's hard to say if you are still working on them or not.

@potiuk I put them in draft first to make sure all checks pass here as well. Only then I switch them to ready, so you won't accidentally get noticed by something that I have to fix first. Thought this was the best way to go.

It's ok to have failing tests on "ready to review" PR. We have pretty asynchronous process of reviews and it is triggererd by various events, and you want to maximise the chance someone will have time to look at your PR - sometimes even before you fix all the issues there. Failing tests on such prs also help the reviewer to see potential problems, and give the chance of reviewing them while you are also fixing them :)

Besides - you can always run the tests locally- using local venv or Breeze. There is no particular reason to use CI to check if tests are passing. Our system is generally prepared for the contributor to run the tests locally and fix them before submiting the PRs. Especially in your case, it's worth to spend (literally) 10 minutes in setting up the breeze environment and running pre-commit install in your repo to be able to replicate 1-1 what CI is doing - especially when you localize your changes to individual modules now. Usually the test for module in question are localted in corresponding tests subdirectory. So-for example when you make changes to "airlfow/models" like in this case, you can replicate the same thing that our CI is doing:

All described here: https://github.com/apache/airflow/blob/main/CONTRIBUTORS_QUICK_START.rst

There are two ways:

• setup your local venv
• Connect your IDE to it
• Use Run test as usual - for example right-click on tests/models and selecting Run tests. You just need to be sure you have pytest runner configured as default (all details in our contributing docs where you will find screenshots for Pycharm, VScode and even Codespaces or GitPod if you prefer to work in the cloud),

Using breeze:

This is more heavy (requires docker and docker-compose) but it replicates exactly what CI does with all the dependencies and configurations so you can be almost 100% sure what passes there, passes on CI.

1. Run breeze -> you enter the same container that the CI tests run in
2. Once in container run pytest tests/models

All details on setting up Breeze in https://github.com/apache/airflow/blob/main/BREEZE.rst

With the number of changes and PRs you have - investing in setting it up will give you a lot of saved time on waiting for CI.

Thank you, @potiuk. Set breeze up and now it tests locally.

Cool.