02_customizing.rst

Customizing breeze environment

Breeze can be customized in a number of ways. You can read about those ways in this document.

• Customizing Breeze startup
• Additional tools in Breeze container
• Launching Breeze integrations
• Setting default answers for user interaction

Customizing Breeze startup

When you enter the Breeze environment, automatically an environment file is sourced from files/airflow-breeze-config/variables.env.

You can also add files/airflow-breeze-config/init.sh and the script will be sourced always when you enter Breeze. For example you can add pip install commands if you want to install custom dependencies - but there are no limits to add your own customizations.

You can override the name of the init script by setting INIT_SCRIPT_FILE environment variable before running the breeze environment.

You can also customize your environment by setting BREEZE_INIT_COMMAND environment variable. This variable will be evaluated at entering the environment.

The files folder from your local sources is automatically mounted to the container under /files path and you can put there any files you want to make available for the Breeze container.

You can also copy any .whl or .sdist packages to dist and when you pass --use-packages-from-dist flag as wheel or sdist line parameter, breeze will automatically install the packages found there when you enter Breeze.

You can also add your local tmux configuration in files/airflow-breeze-config/.tmux.conf and these configurations will be available for your tmux environment.

There is a symlink between files/airflow-breeze-config/.tmux.conf and ~/.tmux.conf in the container, so you can change it at any place, and run

tmux source ~/.tmux.conf

inside container, to enable modified tmux configurations.

Additional tools in Breeze container

To shrink the Docker image, not all tools are pre-installed in the Docker image. But we have made sure that there is an easy process to install additional tools.

Additional tools are installed in /files/bin. This path is added to $PATH, so your shell will automatically autocomplete files that are in that directory. You can also keep the binaries for your tools in this directory if you need to.

Installation scripts

For the development convenience, we have also provided installation scripts for commonly used tools. They are installed to /files/opt/, so they are preserved after restarting the Breeze environment. Each script is also available in $PATH, so just type install_<TAB> to get a list of tools.

Currently available scripts:

• install_aws.sh - installs the AWS CLI including
• install_az.sh - installs the Azure CLI including
• install_gcloud.sh - installs the Google Cloud SDK including gcloud, gsutil.
• install_imgcat.sh - installs imgcat - Inline Images Protocol for iTerm2 (Mac OS only)
• install_java.sh - installs the OpenJDK 8u41
• install_kubectl.sh - installs the Kubernetes command-line tool, kubectl
• install_snowsql.sh - installs SnowSQL
• install_terraform.sh - installs Terraform

Launching Breeze integrations

When Breeze starts, it can start additional integrations. Those are additional docker containers that are started in the same docker-compose command. Those are required by some of the tests as described in ../../../contributing-docs/testing/integration-tests.rst.

By default Breeze starts only airflow container without any integration enabled. If you selected postgres or mysql backend, the container for the selected backend is also started (but only the one that is selected). You can start the additional integrations by passing --integration flag with appropriate integration name when starting Breeze. You can specify several --integration flags to start more than one integration at a time. Finally you can specify --integration all-testable to start all testable integrations and --integration all to enable all integrations.

Once integration is started, it will continue to run until the environment is stopped with breeze down command.

Note that running integrations uses significant resources - CPU and memory.

Setting default answers for user interaction

Sometimes during the build, you are asked whether to perform an action, skip it, or quit. This happens when rebuilding or removing an image and in few other cases - actions that take a lot of time or could be potentially destructive. You can force answer to the questions by providing an --answer flag in the commands that support it.

For automation scripts, you can export the ANSWER variable (and set it to y, n, q, yes, no, quit - in all case combinations).

export ANSWER="yes"

---

Next step: Follow the Developer tasks guide to learn how to use Breeze for regular development tasks.