-
Notifications
You must be signed in to change notification settings - Fork 14.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to override concrete --postgres-version/--mysql-version #38133
Allow to override concrete --postgres-version/--mysql-version #38133
Conversation
Hmm, I think now MySQL/Postgres tests is gone 🤔 |
Yep. One more thing to add later today :). But I am close to get rid of 1300 or so lines of CI.yml after that one :) |
84241b4
to
52ded78
Compare
Much better @Taragolis -> I have also checked (who tests the tests) that it correctly uses the right postgres/mysql version in the tests (POSTGRES_VERSION/MYSQL_VERSION variables are set properly and we have explicit diagnostics message when shell is entered displaying backend + version used. |
52ded78
to
765f3df
Compare
I also added a bit of documentation explaining the |
Thanks for doing that, I did not quite understand the PR before reading it |
765f3df
to
28a7f04
Compare
The `BACKEND_VERSION` env variable is now generic way to override any version of any backend. When you set it before running breeze and when the value maches possible options for given platform, the value of concrete backend version will be overridden from the variable. This will be helpful to generalize a bit and make reusable test workflow where `BACKEND_VERSION` will be treated in simiar way in all tests.
28a7f04
to
fbc4016
Compare
The
BACKEND_VERSION
env variable is now generic way to override any version of any backend. When you set it before running breeze and when the value maches possible options for given platform, the value of concrete backend version will be overridden from the variable.This will be helpful to generalize a bit and make reusable test workflow where
BACKEND_VERSION
will be treated in simiar way in all tests.^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rst
or{issue_number}.significant.rst
, in newsfragments.