For your information - the last PR has been merged
https://github.com/apache/airflow/pull/39862 and our CI should now run a
full set of Provider unit tests with Airflow 2.9.1. 2.8.4 and 2.7.3 - thus
giving us more confidence that provider changes do not depend on features
implemented in newer vers
The 2.9 compatibility tests are now merged ! The 2.8 PR is almost ready
as a follow up and the next thing will be 2.7.
Small thing for everyone to take a look at now is to make sure the tests
are also passing 2.9 (and later 2.8 and 2.7) - but this should be just a
job failing in your PRs if they
OK. Tests should be green now - all the issues are "handled" - there are
few follow up tasks from the tests run on 2.9.1 but the PR should be quite
ready for final review and merge now and I can attempt to look at 2.8
compatibility once it's done.
On Mon, May 13, 2024 at 1:17 AM Jarek Potiuk wrot
OK. I think I found and fixed all the compatibility issues in
https://github.com/apache/airflow/pull/39513 - except one last openlineage
plugin enablement fix (but I think reviews for all the other changes
would be great until we fix the issue). There are probably a few
incompatibilities that will
> Just for clarification, this is only related to the provider's tests,
right?
Absolutely.
On Fri, May 10, 2024 at 11:21 AM Andrey Anshin
wrote:
> > "enable" tests for 2.8 and 2.7 separately
>
> Just for clarification, this is only related to the provider's tests,
> right?
>
>
>
> On Fri, 10 Ma
> "enable" tests for 2.8 and 2.7 separately
Just for clarification, this is only related to the provider's tests, right?
On Fri, 10 May 2024 at 13:15, Jarek Potiuk wrote:
> > Regarding Airflow 2.7 and Airflow 2.8 in the time we are ready to move
> forward to the initial version of Airflow 3 p
> Regarding Airflow 2.7 and Airflow 2.8 in the time we are ready to move
forward to the initial version of Airflow 3 providers might already drop
support of these versions in providers.
Airflow 2.7 in the mid of August 2024
Airflow 2.8 in the mid of December 2024
Yep. But also "here and now" those
BTW, forget to mention that we should also check Pytest: Good Integration
Practices from
https://docs.pytest.org/en/stable/explanation/goodpractices.html
On Fri, 10 May 2024 at 13:07, Andrey Anshin
wrote:
> I think the current solution with run tests against installed packages
> might help w
I think the current solution with run tests against installed packages
might help with future modifications and develop new dev experience. And
what is more important is help to find problems and incompatibilities of
providers with the previous version of Airflow "here and now".
Regarding Airflow
And yes - as we get down to 2.8 and 2.7 it might be possible that we will
already implement some of the simplifications you mentioned as it might be
easier than adding back-compatiblity to the current ways. I assume it will
be `quite` a bit harder to make our test suite work with Airflow 2.8 and
th
Yep. I think these are all good ideas, and I think this should be part of
our big Airflow 2 vs. Airflow 3 discussion. Almost as important as what is
in and what is out is where and how development of different components
happen. Same repo? Different repos? Different branches? Single monorepo for
Ai
Great job, Jarek!
I would have some proposals, which should be considered as a long term
We should rework our test structure to fully run provider tests without
touching the Core tests.
The main problem here is that we configure a lot of things into the root
conftest.py which might be a problem
Hello everyone,
As part of preparation for the Airflow 3 move and (possible) provider
separation (I have some ideas how to do it but that should be a separate
discussion) I took on the task of improving our compatibility tests for
Providers. I discussed it briefly with Kaxil and Ash and decided to
13 matches
Mail list logo
