-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Consolidate environment variable calculation in ShellParams in Breeze #35801
Conversation
This is a small follow-up after #35768 - this time not about --build-arg generation by breeze but about env variables passed to docker-compose/docker. The way it was done was quite a bit complex - and coming from the previous Bash implementation. This is I think the last remnant of the old Bash approach in Breeze's Python code :). We still have a few scripts in the container, but I think that one was the last thing that resembled the Bash version of Breeze. cc: @Bowrna @edithturn :D |
BTW, I am going to separate out small part of it - fixes to pre-commit attempting to upgrade itself in a few pre-commits (which slowed them down and made it impossible to run them in the plain without network) |
There you go : #35802 |
810ec54
to
589767c
Compare
BTW. This one will make it SO MUCH EASIER to understand and add new variables if we need to :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
589767c
to
25cb870
Compare
Some celery URL passing problem - will take a look tomorrow :) |
25cb870
to
d0f017b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
d0f017b
to
39f1e93
Compare
Actually - I made it even better (see the latest version). I also figured how to do it so that we do not have to keep the separate lists of variables to pass in neither docker-compose base.yaml nor in docker.env - we are now generating the files with the list of variables for both docker and docker-compose. After this change there is only one place where you need to add env variable to pass to docker (ShellParamss |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me. 👍
39f1e93
to
e9d99d8
Compare
Historically (when moved from Bash) the environment variables set for docker or docker-compose commands were set in a few places - some were set directly in the code, some were retrieved from shell params and eventually some were set from default values or hardcoded constants. This all happened in various models and it was scattered around the code and it was difficult to grasp what was going on. This PR consolidates it so that all variables are set in ShellParams object. * the attributes have been reviewed and None/"" default values were set where needed * the attributes were sorted * calculation of dynamic properties was moved to ShellParams * missing properties were added to ShellParams, so that all variables have corresponding properties * the get_env_variables_for_docker_commands is now a method in ShellParams object, mapping is done explicitly from self.ATTRIBUTE and default values if not set are set in this single place if not set in case the variables are are retrieved from elsewhere * we use ShellParams in all places where we execute docker commands (we used BuildCiParams) sometimes needlessly * tests are added to cover the "attribute" + "incoming env var" to the env vars passed to Docker Compose/Docker Most importantly the docker and docker-compose env files are now automatically generated and git-ignored so that we only need to maintain the list of variables to pass in a single plase - in ShellParams `env_variables_for_docker_commands` method.
8568739
to
b1691d3
Compare
…#35801) Historically (when moved from Bash) the environment variables set for docker or docker-compose commands were set in a few places - some were set directly in the code, some were retrieved from shell params and eventually some were set from default values or hardcoded constants. This all happened in various models and it was scattered around the code and it was difficult to grasp what was going on. This PR consolidates it so that all variables are set in ShellParams object. * the attributes have been reviewed and None/"" default values were set where needed * the attributes were sorted * calculation of dynamic properties was moved to ShellParams * missing properties were added to ShellParams, so that all variables have corresponding properties * the get_env_variables_for_docker_commands is now a method in ShellParams object, mapping is done explicitly from self.ATTRIBUTE and default values if not set are set in this single place if not set in case the variables are are retrieved from elsewhere * we use ShellParams in all places where we execute docker commands (we used BuildCiParams) sometimes needlessly * tests are added to cover the "attribute" + "incoming env var" to the env vars passed to Docker Compose/Docker Most importantly the docker and docker-compose env files are now automatically generated and git-ignored so that we only need to maintain the list of variables to pass in a single plase - in ShellParams `env_variables_for_docker_commands` method.
Some of our pre-commits were using code from Breeze in rather complex way - by inserting PYTHONPATH and importing code from there. That was complex and brittle and with recent changes of ShelParam apache#35801 those precommits required more and more dependencies to be added to their pre-commit virtualenvs. The reason that it was done this way was the assumption that someone might want to run pre-commits locally without having breeze installed, but this assumption and use case is rather unlikely, becasue breeze becomes more and more useful and used so we can safely assume that anyone who wants to do pre-commits will also have breeze installed and on path. And anyway to run those pre-commits you need to have breeze CI image pulled and built, so you should generally have breeze to run them. This PR finishes the series of PRs implementing the refactor and completes the refactor.
#35830) Some of our pre-commits were using code from Breeze in rather complex way - by inserting PYTHONPATH and importing code from there. That was complex and brittle and with recent changes of ShelParam #35801 those precommits required more and more dependencies to be added to their pre-commit virtualenvs. The reason that it was done this way was the assumption that someone might want to run pre-commits locally without having breeze installed, but this assumption and use case is rather unlikely, becasue breeze becomes more and more useful and used so we can safely assume that anyone who wants to do pre-commits will also have breeze installed and on path. And anyway to run those pre-commits you need to have breeze CI image pulled and built, so you should generally have breeze to run them. This PR finishes the series of PRs implementing the refactor and completes the refactor.
#35830) Some of our pre-commits were using code from Breeze in rather complex way - by inserting PYTHONPATH and importing code from there. That was complex and brittle and with recent changes of ShelParam #35801 those precommits required more and more dependencies to be added to their pre-commit virtualenvs. The reason that it was done this way was the assumption that someone might want to run pre-commits locally without having breeze installed, but this assumption and use case is rather unlikely, becasue breeze becomes more and more useful and used so we can safely assume that anyone who wants to do pre-commits will also have breeze installed and on path. And anyway to run those pre-commits you need to have breeze CI image pulled and built, so you should generally have breeze to run them. This PR finishes the series of PRs implementing the refactor and completes the refactor. (cherry picked from commit 8a67e15)
Historically (when moved from Bash) the environment variables set for docker or docker-compose commands were set in a few places - some were set directly in the code, some were retrieved from shell params and eventually some were set from default values or hardcoded constants. This all happened in various models and it was scattered around the code and it was difficult to grasp what was going on.
This PR consolidates it so that all variables are set in ShellParams object.
Most importantly the docker and docker-compose env files are now automatically generated and git-ignored so that we only need to maintain the list of variables to pass in a single plase - in ShellParams
env_variables_for_docker_commands
method.^ 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.