[v3-0-test] Unify selecting constraints option when installing airflow (apache#52274)

Due to the way how it historically got added - we had two ways of
selecting whether we are installing airlfow dyanmically in breeze
with or without constraints:

* --install-airflow-with-constraints - was used in a few places
* --skip-airflow-constraints - was used in other places

The logic to handle those were broken at places where they
contradicted each other. This PR unifies it and only uses
the --install-airflow-with-constraints flag in all the places
where we need to determine whether constraints are used or not
and it fixes the logic.

The logic of installation had been reviewed, refactored into
separate methods doing smaller tasks and more diagnostics was
added.
(cherry picked from commit 8846bef)

Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

Author: potiuk

.github/workflows/test-providers.yml

@@ -138,7 +138,8 @@ jobs:
       - name: "Install and verify wheel provider distributions"
         env:
           DISTRIBUTION_FORMAT: ${{ matrix.package-format }}
-          AIRFLOW_SKIP_CONSTRAINTS: "${{ inputs.upgrade-to-newer-dependencies }}"
+          # yamllint disable rule:line-length
+          INSTALL_AIRFLOW_WITH_CONSTRAINTS: "${{ inputs.upgrade-to-newer-dependencies == 'true' && 'false' || 'true' }}"
         run: >
           breeze release-management verify-provider-distributions
           --use-distributions-from-dist

dev/breeze/doc/01_installation.rst

@@ -157,6 +157,17 @@ We highly recommend using ``uv`` to manage your Python environments, as it is ve
 easy to use, it is faster than any of the other tools availables (way faster!) and has a lot of features
 that make it easier to work with Python.
 
+The ``gh`` cli needed for release managers
+------------------------------------------
+
+The ``gh`` GitHub CLI is a command line tool that allows you to interact with GitHub repositories, issues, pull
+requests, and more. It is useful for release managers to automate tasks such as creating releases,
+managing issues, and starting workflows (for example during documentation building). Release
+managers should have ``gh`` installed (see `gh installation guide <https://github.com/cli/cli>`_) and they
+should follow configuration steps to authorize ``gh`` in their local airflow repository (basically
+running ``gh auth login`` command and following the instructions).
+
+
 Alternative: pipx tool
 ----------------------
 

dev/breeze/doc/02_customizing.rst

@@ -93,6 +93,12 @@ that you may find helpful.
   bind -T root C-S-Up select-pane -U
   bind -T root C-S-Down select-pane -D
 
+  # quickly disable mouse + zoom pane (for easy copying)
+  bind c run-shell "tmux setw mouse off" \; resize-pane -Z \; display-message "🚫 Mouse disabled & pane zoomed"
+
+  # quickly re-enable mouse + unzoom pane (restore normal behavior)
+  bind v run-shell "tmux setw mouse on" \; resize-pane -Z \; display-message "🖱️ Mouse enabled & pane unzoomed"
+
 Some helpful commands:
 
   - ``ctrl-b + z``: zoom into selected pane
@@ -106,6 +112,10 @@ To copy an entire pane:
   - extend selection to end: ``G``
   - copy and clear selection: ``enter``
 
+.. tip::
+
+  You can add the custom bindings (like ``bind c`` and ``bind v``) directly to ``files/airflow-breeze-config/.tmux.conf``.
+  This way they will be automatically loaded when you start a Breeze tmux session.
 
 Additional tools in Breeze container
 ------------------------------------
@@ -143,12 +153,12 @@ When Breeze starts, it can start additional integrations. Those are additional d
 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
+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
+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

dev/breeze/doc/03_developer_tasks.rst

@@ -112,7 +112,7 @@ When you run Airflow Breeze, the following ports are automatically forwarded:
 .. code-block::
 
     * 12322 -> forwarded to Airflow ssh server -> airflow:22
-    * 28080 -> forwarded to Airflow API server or webserver -> airflow:8080
+    * 28080 -> forwarded to Airflow API server -> airflow:8080
     * 25555 -> forwarded to Flower dashboard -> airflow:5555
     * 25433 -> forwarded to Postgres database -> postgres:5432
     * 23306 -> forwarded to MySQL database  -> mysql:3306
@@ -124,20 +124,23 @@ You can connect to these ports/databases using:
 .. code-block::
 
     * ssh connection for remote debugging: ssh -p 12322 airflow@localhost pw: airflow
-    * API server or webserver:    http://localhost:28080
+    * API server:    http://localhost:28080
     * Flower:    http://localhost:25555
     * Postgres:  jdbc:postgresql://localhost:25433/airflow?user=postgres&password=airflow
     * Mysql:     jdbc:mysql://localhost:23306/airflow?user=root
     * Redis:     redis://localhost:26379/0
 
 If you do not use ``start-airflow`` command. You can use ``tmux`` to multiply terminals.
-You may need to create a user prior to running the webserver in order to log in.
+You may need to create a user prior to running the API server in order to log in.
 This can be done with the following command:
 
 .. code-block:: bash
 
     airflow users create --role Admin --username admin --password admin --email admin@example.com --firstname foo --lastname bar
 
+.. note::
+    ``airflow users`` command is only available when `FAB auth manager <https://airflow.apache.org/docs/apache-airflow-providers-fab/stable/auth-manager/index.html>`_ is enabled.
+
 For databases, you need to run ``airflow db reset`` at least once (or run some tests) after you started
 Airflow Breeze to get the database/tables created. You can connect to databases with IDE or any other
 database client:
@@ -152,7 +155,7 @@ database client:
 You can change the used host port numbers by setting appropriate environment variables:
 
 * ``SSH_PORT``
-* ``WEB_HOST_PORT`` - API server for Airflow 3, or webserver port for Airflow 2 when --use-airflow-version is used
+* ``WEB_HOST_PORT`` - API server when --use-airflow-version is used
 * ``POSTGRES_HOST_PORT``
 * ``MYSQL_HOST_PORT``
 * ``MSSQL_HOST_PORT``
@@ -221,6 +224,10 @@ short ``provider id`` (might be multiple of them).
 
      breeze build-docs <provider id> <provider id>
 
+To build documentation for Task SDK package, use the below command
+.. code-block:: bash
+     breeze build-docs task-sdk
+
 or you can use package filter. The filters are glob pattern matching full
 package names and can be used to select more than one package with single filter.
 
@@ -352,7 +359,7 @@ For testing Airflow you often want to start multiple components (in multiple ter
 built-in ``start-airflow`` command that start breeze container, launches multiple terminals using tmux
 and launches all Airflow necessary components in those terminals.
 
-When you are starting airflow from local sources, www asset compilation is automatically executed before.
+When you are starting Airflow from local sources, www asset compilation is automatically executed before.
 
 .. code-block:: bash
 
@@ -391,8 +398,8 @@ These are all available flags of ``start-airflow`` command:
 Launching multiple terminals in the same environment
 ----------------------------------------------------
 
-Often if you want to run full airflow in the Breeze environment you need to launch multiple terminals and
-run ``airflow webserver``, ``airflow scheduler``, ``airflow worker`` in separate terminals.
+Often if you want to run full Airflow in the Breeze environment you need to launch multiple terminals and
+run ``airflow api-server``, ``airflow scheduler``, ``airflow worker`` in separate terminals.
 
 This can be achieved either via ``tmux`` or via exec-ing into the running container from the host. Tmux
 is installed inside the container and you can launch it with ``tmux`` command. Tmux provides you with the
@@ -417,8 +424,8 @@ These are all available flags of ``exec`` command:
 Compiling ui assets
 --------------------
 
-Airflow webserver needs to prepare www assets - compiled with node and yarn. The ``compile-ui-assets``
-command takes care about it. This is needed when you want to run webserver inside of the breeze.
+Airflow API server needs to prepare www assets - compiled with node and yarn. The ``compile-ui-assets``
+command takes care about it. This is needed when you want to run API server inside of the breeze.
 
 .. image:: ./images/output_compile-ui-assets.svg
   :target: https://raw.githubusercontent.com/apache/airflow/main/dev/breeze/images/output_compile-ui-assets.svg
@@ -439,7 +446,7 @@ Breeze uses docker images heavily and those images are rebuild periodically and
 images in docker cache. This might cause extra disk usage. Also running various docker compose commands
 (for example running tests with ``breeze testing core-tests``) might create additional docker networks that might
 prevent new networks from being created. Those networks are not removed automatically by docker-compose.
-Also Breeze uses it's own cache to keep information about all images.
+Also Breeze uses its own cache to keep information about all images.
 
 All those unused images, networks and cache can be removed by running ``breeze cleanup`` command. By default
 it will not remove the most recent images that you might need to run breeze commands, but you
@@ -458,7 +465,7 @@ These are all available flags of ``cleanup`` command:
 Database and config volumes in Breeze
 -------------------------------------
 
-Breeze keeps data for all it's integration, database, configuration in named docker volumes.
+Breeze keeps data for all its integration, database, configuration in named docker volumes.
 Those volumes are persisted until ``breeze down`` command. You can also preserve the volumes by adding
 flag ``--preserve-volumes`` when you run the command. Then, next time when you start Breeze,
 it will have the data pre-populated.
@@ -494,7 +501,7 @@ Running Breeze with a StatsD Metrics Stack
 ..........................................
 
 You can launch an instance of Breeze pre-configured to emit StatsD metrics using
-``breeze start-airflow --integration statsd``.  This will launch an Airflow webserver
+``breeze start-airflow --integration statsd``.  This will launch an Airflow API server
 within the Breeze environment as well as containers running StatsD, Prometheus, and
 Grafana.  The integration configures the "Targets" in Prometheus, the "Datasources" in
 Grafana, and includes a default dashboard in Grafana.
@@ -547,9 +554,9 @@ Running Breeze with OpenLineage
 ...............................
 
 You can launch an instance of Breeze pre-configured to emit OpenLineage metrics using
-``breeze start-airflow --integration openlineage``.  This will launch an Airflow webserver
+``breeze start-airflow --integration openlineage``.  This will launch an Airflow API server
 within the Breeze environment as well as containers running a [Marquez](https://marquezproject.ai/)
-webserver and API server.
+API server.
 
 When you run Airflow Breeze with this integration, in addition to the standard ports
 (See "Port Forwarding" below), the following are also automatically forwarded:

dev/breeze/doc/05_test_commands.rst

@@ -68,7 +68,7 @@ To run the whole test class:
 You can re-run the tests interactively, add extra parameters to pytest  and modify the files before
 re-running the test to iterate over the tests. You can also add more flags when starting the
 ``breeze shell`` command when you run integration tests or system tests. Read more details about it
-in the `testing doc </contributing-docs/testing.rst>`_ where all the test types and information on how to run them are explained.
+in the `testing doc </contributing-docs/09_testing.rst>`_ where all the test types and information on how to run them are explained.
 
 This applies to all kind of tests - all our tests can be run using pytest.
 
@@ -159,7 +159,7 @@ Here is the detailed set of options for the ``breeze testing providers-test`` co
 Using ``breeze testing task-sdk-tests`` command
 ...............................................
 
-The ``breeze testing task-sdk-tests`` command is  allows you to run tests for Task SDK without
+The ``breeze testing task-sdk-tests`` command allows you to run tests for Task SDK without
 initializing database. The Task SDK should not need database to be started so this acts as a
 good check to see if the Task SDK tests are working properly.
 
@@ -241,7 +241,7 @@ Here is the detailed set of options for the ``breeze testing providers-integrati
 Running Python API client tests
 ...............................
 
-To run Python API client tests, you need to have airflow python client packaged in dist folder.
+To run Python API client tests, you need to have Airflow python client packaged in dist folder.
 To package the client, clone the airflow-python-client repository and run the following command:
 
 .. code-block:: bash
@@ -327,7 +327,7 @@ automatically to run the tests.
 You can:
 
 * Setup environment for k8s tests with ``breeze k8s setup-env``
-* Build airflow k8S images with ``breeze k8s build-k8s-image``
+* Build Airflow k8S images with ``breeze k8s build-k8s-image``
 * Manage KinD Kubernetes cluster and upload image and deploy Airflow to KinD cluster via
   ``breeze k8s create-cluster``, ``breeze k8s configure-cluster``, ``breeze k8s deploy-airflow``, ``breeze k8s status``,
   ``breeze k8s upload-k8s-image``, ``breeze k8s delete-cluster`` commands
@@ -398,7 +398,7 @@ Building Airflow K8s images
 ...........................
 
 Before deploying Airflow Helm Chart, you need to make sure the appropriate Airflow image is build (it has
-embedded test dags, pod templates and webserver is configured to refresh immediately. This can
+embedded test dags, pod templates and api-server is configured to refresh immediately. This can
 be done via ``breeze k8s build-k8s-image`` command. It can also be done in parallel for all images via
 ``--run-in-parallel`` flag.
 
@@ -412,7 +412,7 @@ All parameters of the command are here:
 Uploading Airflow K8s images
 ............................
 
-The K8S airflow images need to be uploaded to the KinD cluster. This can be done via
+The K8S Airflow images need to be uploaded to the KinD cluster. This can be done via
 ``breeze k8s upload-k8s-image`` command. It can also be done in parallel for all images via
 ``--run-in-parallel`` flag.
 
@@ -442,7 +442,7 @@ Deploying Airflow to the Cluster
 
 Airflow can be deployed to the Cluster with ``breeze k8s deploy-airflow``. This step will automatically
 (unless disabled by switches) will rebuild the image to be deployed. It also uses the latest version
-of the Airflow Helm Chart to deploy it. You can also choose to upgrade existing airflow deployment
+of the Airflow Helm Chart to deploy it. You can also choose to upgrade existing Airflow deployment
 and pass extra arguments to ``helm install`` or ``helm upgrade`` commands that are used to
 deploy airflow. By passing ``--run-in-parallel`` the deployment can be run
 for all clusters in parallel.
@@ -457,7 +457,7 @@ All parameters of the command are here:
 Checking status of the K8S cluster
 ..................................
 
-You can delete kubernetes cluster and airflow deployed in the current cluster
+You can delete kubernetes cluster and Airflow deployed in the current cluster
 via ``breeze k8s status`` command. It can be also checked for all clusters created so far by passing
 ``--all`` flag.
 
@@ -517,7 +517,7 @@ Running k8s complete tests
 ..........................
 
 You can run ``breeze k8s run-complete-tests`` command to combine all previous steps in one command. That
-command will create cluster, deploy airflow and run tests and finally delete cluster. It is used in CI
+command will create cluster, deploy Airflow and run tests and finally delete cluster. It is used in CI
 to run the whole chains in parallel.
 
 Run all tests:
@@ -575,7 +575,7 @@ as executor you use, similar to:
 
 The shell automatically activates the virtual environment that has all appropriate dependencies
 installed and you can interactively run all k8s tests with pytest command (of course the cluster need to
-be created and airflow deployed to it before running the tests):
+be created and Airflow deployed to it before running the tests):
 
 .. code-block:: bash
 

dev/breeze/doc/06_managing_docker_images.rst

@@ -196,7 +196,7 @@ but here typical examples are presented:
 
      breeze prod-image build --additional-airflow-extras "jira"
 
-This installs additional ``jira`` extra while installing airflow in the image.
+This installs additional ``jira`` extra while installing Airflow in the image.
 
 
 .. code-block:: bash

dev/breeze/doc/10_advanced_breeze_topics.rst

@@ -117,7 +117,7 @@ which will be mapped to ``/files`` in your Docker container. You can pass there
 configure and run Docker. They will not be removed between Docker runs.
 
 By default ``/files/dags`` folder is mounted from your local ``<AIRFLOW_ROOT_PATH>/files/dags`` and this is
-the directory used by airflow scheduler and webserver to scan dags for. You can use it to test your dags
+the directory used by Airflow scheduler and api-server to scan dags for. You can use it to test your dags
 from local sources in Airflow. If you wish to add local DAGs that can be run by Breeze.
 
 The ``/files/airflow-breeze-config`` folder contains configuration files that might be used to
@@ -132,7 +132,7 @@ There are couple of things you might want to do when adding/changing dependencie
 Breeze. You can add dependencies temporarily (which will last until you exit Breeze shell), or you might
 want to add them permanently (which require you to rebuild the image). Also there are different things
 you need to do when you are adding system level (debian) level, Python (pip) dependencies or Node (yarn)
-dependencies for the webserver.
+dependencies for the api-server.
 
 Python dependencies
 ...................

dev/breeze/doc/ci/02_images.md

@@ -443,7 +443,7 @@ can be used for CI images:
 | `ADDITIONAL_DEV_APT_DEPS`         |                            | Additional apt dev dependencies installed in the first part of the image                                          |
 | `ADDITIONAL_DEV_APT_ENV`          |                            | Additional env variables defined when installing dev deps                                                         |
 | `AIRFLOW_PIP_VERSION`             | `25.1.1`                   | `pip` version used.                                                                                               |
-| `AIRFLOW_UV_VERSION`              | `0.7.8`                    | `uv` version used.                                                                                                |
+| `AIRFLOW_UV_VERSION`              | `0.7.14`                   | `uv` version used.                                                                                                |
 | `AIRFLOW_PRE_COMMIT_VERSION`      | `4.2.0`                    | `pre-commit` version used.                                                                                        |
 | `AIRFLOW_PRE_COMMIT_UV_VERSION`   | `4.1.4`                    | `pre-commit-uv` version used.                                                                                     |
 | `AIRFLOW_USE_UV`                  | `true`                     | Whether to use UV for installation.                                                                               |