refactor: rename docker-compose files and update references (#33790)

Signed-off-by: Vladislav Polyakov <polRk@ydb.tech>

docs/docs/configuration/alerts-reports.mdx

@@ -42,7 +42,7 @@ Note: All the components required (Firefox headless browser, Redis, Postgres db,
 All you need to do is add the required config variables described in this guide (See `Detailed Config`).
 
 If you are running a non-dev docker image, e.g., a stable release like `apache/superset:3.1.0`, that image does not include a headless browser.  Only the `superset_worker` container needs this headless browser to browse to the target chart or dashboard.
-You can either install and configure the headless browser - see "Custom Dockerfile" section below - or when deploying via `docker compose`, modify your `docker-compose.yml` file to use a dev image for the worker container and a stable release image for the `superset_app` container.
+You can either install and configure the headless browser - see "Custom Dockerfile" section below - or when deploying via `docker compose`, modify your `compose.yml` file to use a dev image for the worker container and a stable release image for the `superset_app` container.
 
 *Note*: In this context, a "dev image" is the same application software as its corresponding non-dev image, just bundled with additional tools.  So an image like `3.1.0-dev` is identical to `3.1.0` when it comes to stability, functionality, and running in production.  The actual "in-development" versions of Superset - cutting-edge and unstable - are not tagged with version numbers on Docker Hub and will display version `0.0.0-dev` within the Superset UI.
 
@@ -74,7 +74,7 @@ Note: when you configure an alert or a report, the Slack channel list takes chan
 
 ### Docker Compose specific
 
-#### You must have in your `docker-compose.yml`
+#### You must have in your `compose.yml`
 
 - A Redis message broker
 - PostgreSQL DB instead of SQLlite

docs/docs/configuration/databases.mdx

@@ -127,7 +127,7 @@ into the container from PyPI at runtime. This file will be ignored by Git for
 the purposes of local development.
 
 Create the file `requirements-local.txt` in a subdirectory called `docker` that
-exists in the directory with your `docker-compose.yml` or `docker-compose-non-dev.yml` file.
+exists in the directory with your `compose.yml` or `compose-non-dev.yml` file.
 
 ```bash
 # Run from the repo root:
@@ -142,7 +142,7 @@ echo "mysqlclient" >> ./docker/requirements-local.txt
 ```
 
 **If you are running a stock (non-customized) Superset image**, you are done.
-Launch Superset with `docker compose -f docker-compose-non-dev.yml up` and
+Launch Superset with `docker compose -f compose-non-dev.yml up` and
 the driver should be present.
 
 You can check its presence by entering the running container with

docs/docs/contributing/development.mdx

@@ -49,7 +49,7 @@ Note that:
   - **Redis** as the message queue for our async backend and caching backend
 - It'll load up examples into the database upon the first startup
 - all other details and pointers available in
-  [docker-compose.yml](https://github.com/apache/superset/blob/master/docker-compose.yml)
+  [compose.yml](https://github.com/apache/superset/blob/master/compose.yml)
 - The local repository is mounted within the services, meaning updating
   the code on the host will be reflected in the docker images
 - Superset is served at localhost:9000/

docs/docs/installation/docker-compose.mdx

@@ -28,14 +28,14 @@ way to launch a fully functioning **development environment** quickly.
 
 Note that there are 3 major ways we support to run `docker compose`:
 
-1. **docker-compose.yml:** for interactive development, where we mount your local folder with the
+1. **compose.yml:** for interactive development, where we mount your local folder with the
   frontend/backend files that you can edit and experience the changes you
   make in the app in real time
-1. **docker-compose-non-dev.yml** where we just build a more immutable image based on the
+1. **compose-non-dev.yml** where we just build a more immutable image based on the
   local branch and get all the required images running. Changes in the local branch
   at the time you fire this up will be reflected, but changes to the code
   while `up` won't be reflected in the app
-1. **docker-compose-image-tag.yml** where we fetch an image from docker-hub say for the
+1. **compose-image-tag.yml** where we fetch an image from docker-hub say for the
   `3.0.0` release for instance, and fire it up so you can try it. Here what's in
   the local branch has no effects on what's running, we just fetch and run
   pre-built images from docker-hub. For `docker compose` to work along with the
@@ -106,7 +106,7 @@ from within docker. This will slow down the startup, but will fix various npm-re
 ### Option #2 - build a set of immutable images from the local branch
 
 ```bash
-docker compose -f docker-compose-non-dev.yml up
+docker compose -f compose-non-dev.yml up
 ```
 
 ### Option #3 - boot up an official release
@@ -121,7 +121,7 @@ git fetch --depth=1 origin tag $TAG
 # Checkout the corresponding git ref
 git checkout $TAG
 # Fire up docker compose
-docker compose -f docker-compose-image-tag.yml up
+docker compose -f compose-image-tag.yml up
 ```
 
 Here various release tags, github SHA, and latest `master` can be referenced by the TAG env var.
@@ -179,7 +179,7 @@ that the logic runs a `from superset_config_docker import *`
 
 :::note
 Users often want to connect to other databases from Superset. Currently, the easiest way to
-do this is to modify the `docker-compose-non-dev.yml` file and add your database as a service that
+do this is to modify the `compose-non-dev.yml` file and add your database as a service that
 the other services depend on (via `x-superset-depends-on`). Others have attempted to set
 `network_mode: host` on the Superset services, but these generally break the installation,
 because the configuration requires use of the Docker Compose DNS resolver for the service names.
@@ -193,8 +193,8 @@ decisions about patching and long-term support. Scarf purges personally identifi
 (PII) and provides only aggregated statistics.
 
 To opt-out of this data collection for packages downloaded through the Scarf Gateway by your docker
-compose based installation, edit the `x-superset-image:` line in your `docker-compose.yml` and
-`docker-compose-non-dev.yml` files, replacing `apachesuperset.docker.scarf.sh/apache/superset` with
+compose based installation, edit the `x-superset-image:` line in your `compose.yml` and
+`compose-non-dev.yml` files, replacing `apachesuperset.docker.scarf.sh/apache/superset` with
 `apache/superset` to pull the image directly from Docker Hub.
 
 To disable the Scarf telemetry pixel, set the `SCARF_ANALYTICS` environment variable to `False` in
@@ -257,4 +257,4 @@ When running `docker compose up`, docker will build what is required behind the
 may use the docker cache if assets already exist. Running `docker compose build` prior to
 `docker compose up` or the equivalent shortcut `docker compose up --build` ensures that your
 docker images matche the definition in the repository. This should only apply to the main
-docker-compose.yml file (default) and not to the alternative methods defined above.
+compose.yml file (default) and not to the alternative methods defined above.

docs/docs/installation/installation-methods.mdx

@@ -19,7 +19,7 @@ The fundamental trade-off is between you needing to do more of the detail work y
 
 If you're not just demoing the software, you'll need a moderate understanding of Docker to customize your deployment and avoid a few risks. Even when fully-optimized this is not as robust a method as Kubernetes when it comes to large-scale production deployments.
 
-You manage a superset-config.py file and a docker-compose.yml file. Docker Compose brings up all the needed services - the Superset application, a Postgres metadata DB, Redis cache, Celery worker and beat. They are automatically connected to each other.
+You manage a superset-config.py file and a compose.yml file. Docker Compose brings up all the needed services - the Superset application, a Postgres metadata DB, Redis cache, Celery worker and beat. They are automatically connected to each other.
 
 **Responsibilities**
 

docs/docs/quickstart.mdx

@@ -35,14 +35,14 @@ $ cd superset
 $ git checkout tags/4.1.2
 
 # Fire up Superset using Docker Compose
-$ docker compose -f docker-compose-image-tag.yml up
+$ docker compose -f compose-image-tag.yml up
 ```
 
 This may take a moment as Docker Compose will fetch the underlying
 container images and will load up some examples. Once all containers
 are downloaded and the output settles, you're ready to log in.
 
-⚠️ If you get an error message like `validating superset\docker-compose-image-tag.yml: services.superset-worker-beat.env_file.0 must be a string`, you need to update your version of `docker-compose`.
+⚠️ If you get an error message like `validating superset\compose-image-tag.yml: services.superset-worker-beat.env_file.0 must be a string`, you need to update your version of `docker-compose`.
 Note that `docker-compose` is on the path to deprecation and you should now use `docker compose` instead.
 
 ### 3. Log into Superset