docs: update docs and formatting

.github/workflows/mkdocs.yml

@@ -13,10 +13,22 @@ jobs:
       - name: Checkout main
         uses: actions/checkout@v4
 
-      - name: Deploy docs
-        uses: mhausenblas/mkdocs-deploy-gh-pages@master
-        # Or use mhausenblas/mkdocs-deploy-gh-pages@nomaterial to build without the mkdocs-material theme
-        env:
-          GITHUB_TOKEN: ${{ secrets.GH_ACTION_PAT }}
-          CONFIG_FILE: ./mkdocs.yml
-          REQUIREMENTS: docs/requirements.txt
+      # - name: Deploy docs
+      #   uses: mhausenblas/mkdocs-deploy-gh-pages@master
+      #   # Or use mhausenblas/mkdocs-deploy-gh-pages@nomaterial to build without the mkdocs-material theme
+      #   env:
+      #     GITHUB_TOKEN: ${{ secrets.GH_ACTION_PAT }}
+      #     CONFIG_FILE: ./mkdocs.yml
+      #     REQUIREMENTS: docs/requirements.txt
+      - name: Build
+        uses: Tiryoh/actions-mkdocs@v0
+        with:
+          mkdocs_version: 'latest' # option
+          #mkdocs_version: '1.1' # option
+          requirements: 'docs/requirements.txt' # option
+          configfile: './mkdocs.yml' # option
+      - name: Deploy
+        uses: peaceiris/actions-gh-pages@v4
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          publish_dir: ./site

docs/_data/defaults.yml

@@ -0,0 +1,16 @@
+name: example.com
+webhookhandler: webhook.example.com
+sshport: 22
+sshhostname: ssh.example.com
+apiaddress: api.example.com
+helpstring: your Lagoon administrator
+helpstring_ja: Lagoon 管理者
+
+## Comment out any of the above, and uncomment the corresponding below to see the variables in action
+# name: amazee.io
+# webhookhandler: webhook.amazeeio.cloud
+# sshport: 32222
+# sshhostname: ssh.amazeeio.cloud
+# apiaddress: api.amazeeio.cloud
+# helpstring: "[amazee.io support](https://support.amazee.io)"
+# helpstring: "[amazee.io support](mailto:[email protected])"

docs/applications/drupal/drush-9.md

@@ -25,7 +25,7 @@ In order to be able to use `drush site:alias-convert` , you need to do the follo
 You can now convert your Drush aliases by running the following command in your project using the `cli` container:
 
 ```bash title="Generate Site Aliases"
-docker-compose exec cli drush site:alias-convert /app/drush/sites --yes
+docker compose exec cli drush site:alias-convert /app/drush/sites --yes
 ```
 
 It's good practice to commit the resulting YAML files into your Git repository, so that they are in place for your fellow developers.

docs/applications/drupal/first-deployment-of-drupal.md

@@ -19,17 +19,17 @@ git push
 
 This will trigger a push, and the Git hosting will inform Lagoon about this push via the configured webhook.
 
-If all is correct, you will see a notification in your configured chat system (this is configured by your friendly Lagoon administrator):
+If all is correct, you will see a notification in your configured chat system. \(Contact {{ defaults.helpstring }} to configure this\):
 
 ![Slack notification of a deployment starting.](../../images/first_deployment_slack_start.jpg)
 
 This tells you that Lagoon has just started to deploy your code. Depending on the size of the codebase and amount of containers, this will take a couple of seconds. Just relax. If you'd like to know what's happening now, check out the [Build and Deploy Process of Lagoon](../../concepts-basics/build-and-deploy-process.md).
 
-You can also check your Lagoon UI to see the progress of any deployment (your Lagoon administrator has the info).
+You can also check your Lagoon UI to see the progress of any deployment. \(Contact {{ defaults.helpstring }} for the URL if you don't have it\).
 
 ## 3. A fail
 
-Depending on the post-rollout tasks defined in `.lagoon.yml` , you might have run some tasks like `drush updb` or `drush cr`. These Drush tasks depend on a database existing within the environment, which obviously does not exist yet. Let's fix that! Keep reading.
+Depending on the post-rollout tasks defined in `.lagoon.yml`, you might have run some tasks like `drush updb` or `drush cr`. These Drush tasks depend on a database existing within the environment, which obviously does not exist yet. Let's fix that! Keep reading.
 
 ## 4. Synchronize local database to the remote Lagoon environment
 
@@ -38,7 +38,7 @@ With full Drush site alias support in Lagoon, you can synchronize a local databa
 !!! warning
     You may have to tell pygmy about your public keys before the next step.
 
-If you get an error like `Permission denied (publickey)`, check out the documentation here: [pygmy - adding ssh keys](https://pygmy.readthedocs.io/en/master/ssh_agent)
+If you get an error like `Permission denied (publickey)`, check out the documentation here: [pygmy - adding ssh keys](https://pygmy.readthedocs.io/en/master/ssh_agent).
 
 First let's make sure that you can see the Drush site aliases:
 
@@ -65,12 +65,12 @@ You should see something like:
 
 ```bash title="Drush sql-sync results"
 [drupal-example]cli-drupal:/app$ drush sql-sync @self @develop
-You will destroy data in ssh.lagoon.amazeeio.cloud/drupal and replace with data from drupal.
+You will destroy data in {{ defaults.sshhostname }}/drupal and replace with data from drupal.
 Do you really want to continue? (y/n): y
 Starting to dump database on Source.                                                                              [ok]
 Database dump saved to /home/drush-backups/drupal/20180227075813/drupal_20180227_075815.sql.gz               [success]
 Starting to discover temporary files directory on Destination.                                                    [ok]
-You will delete files in drupal-example-develop@ssh.lagoon.amazeeio.cloud:/tmp/drupal_20180227_075815.sql.gz and replace with data from /home/drush-backups/drupal/20180227075813/drupal_20180227_075815.sql.gz
+You will delete files in drupal-example-develop@{{ defaults.sshhostname }}:/tmp/drupal_20180227_075815.sql.gz and replace with data from /home/drush-backups/drupal/20180227075813/drupal_20180227_075815.sql.gz
 Do you really want to continue? (y/n): y
 Copying dump file from Source to Destination.                                                                     [ok]
 Starting to import dump file onto Destination database.
@@ -87,7 +87,7 @@ This time all should be green:
 
 ![Deployment Success!](../../images/first_deployment_slack_success.jpg)
 
-Click on the links in the notification, and you should see your Drupal site loaded in all its beauty! It will probably not have images yet, which we will handle in [Step 6](./first-deployment-of-drupal.md#6-synchronize-local-files-to-the-remote-lagoon-environment).
+Click on the links in the notification, and you should see your Drupal site loaded in all its beauty! It will probably not have images yet, which we will handle in [Step 6](./first-deployment-of-drupal.md#5-synchronize-local-files-to-the-remote-lagoon-environment).
 
 If it is still failing, check the logs link for more information.
 
@@ -103,19 +103,19 @@ It should show you something like:
 
 ```bash title="Drush rsync results"
 [drupal-example]cli-drupal:/app$ drush rsync @self:%files @develop:%files
-You will delete files in drupal-example-develop@ssh.lagoon.amazeeio.cloud:/app/web/sites/default/files and replace with data from /app/web/sites/default/files/
+You will delete files in drupal-example-develop@{{ defaults.sshhostname }}:/app/web/sites/default/files and replace with data from /app/web/sites/default/files/
 Do you really want to continue? (y/n): y
 ```
 
 In some cases, though, it might not look correct, like here:
 
 ```bash title="Drush rsync results"
 [drupal-example]cli-drupal:/app$ drush rsync @self:%files @develop:%files
-You will delete files in drupal-example-develop@ssh.lagoon.amazeeio.cloud:'/app/web/%files' and replace with data from '/app/web/%files'/
+You will delete files in drupal-example-develop@{{ defaults.sshhostname }}:'/app/web/%files' and replace with data from '/app/web/%files'/
 Do you really want to continue? (y/n):
 ```
 
-The reason for that is that the Drupal cannot resolve the path of the files directory. This most probably has to do that the Drupal is not fully configured or has a missing database. For a workaround you can use `drush rsync @self:sites/default/files @develop:sites/default/files`, but we suggest that you actually check your local and remote Drupal \(you can test with `drush status` to see if the files directory is correctly configured\).
+The reason for that is that the Drupal cannot resolve the path of the files directory. This most probably has to do with Drupal not being fully configured or having a missing database. For a workaround you can use `drush rsync @self:sites/default/files @develop:sites/default/files`, but we suggest that you actually check your local and remote Drupal \(you can test with `drush status` to see if the files directory is correctly configured\).
 
 ## 6. It's done
 
@@ -141,4 +141,4 @@ That's the beauty of Lagoon: it's exactly the same: Push the branch name you def
 Did the deployment fail? Oh no! But we're here to help:
 
 1. Click on the `logs` link in the error notification. It will tell you where in the deployment process the failure happened.
-2. If you can't figure it out, ask your Lagoon administrator, they are here to help!
+2. If you can't figure it out, contact {{ defaults.helpstring }}, they are here to help!

docs/applications/drupal/phpunit-and-phpstorm.md

@@ -38,7 +38,7 @@
    * Server: `<DOCKER>`
    * Configuration file\(s\): `./docker-compose.yml`
    * Service: `cli`
-   * Lifecycle: `Connect to existing container ('docker-compose exec')`
+   * Lifecycle: `Connect to existing container ('docker compose exec')`
 5. Path mappings:
    * Local path: `<ROOT_PATH>`
    * Remote path\*: `/app`
@@ -79,7 +79,7 @@
 
 ### Some final checks to run before you run a test
 
-1. You have the project up and running:  `$ docker-compose up -d`
+1. You have the project up and running:  `$ docker compose up -d`
 2. The project is working without any errors, visit the site just to make sure it all works as expected - this is not 100% necessary, but nice to know it is working normally.
 3. We should be ready to run some tests!
 

docs/applications/drupal/services/mariadb.md

@@ -37,10 +37,10 @@ $ docker port drupal_example_mariadb_1
 
 Or via `docker-compose` inside a Drupal repository:
 
-Run: `docker-compose port [service_name] [interal_port]`.
+Run: `docker compose port [service_name] [interal_port]`.
 
 ```bash title="Set ports"
-docker-compose port mariab 3306
+docker compose port mariab 3306
 0.0.0.0:32797
 ```
 

docs/applications/drupal/services/varnish.md

@@ -85,7 +85,7 @@ To test Varnish locally, change the following in `docker-compose.yml`:
 
 * Set `VARNISH_BYPASS` to `false` in the Varnish service section.
 * Set `LAGOON_ENVIRONMENT_TYPE` to `production` in the `x-environment` section.
-* Run `docker-compose up -d` , which restarts all services with the new environment variables.
+* Run `docker compose up -d` , which restarts all services with the new environment variables.
 
 Now you should be able to test Varnish!
 <!-- markdown-link-check-disable -->
@@ -127,6 +127,6 @@ Varnish doesn't cache? Or something else not working? Here a couple of ways to d
 <!-- markdown-link-check-disable -->
 * Run `drush p-debug-en` to enable debug logging of the purge module. This should show you debugging in the Drupal log under `admin/reports/dblog`.
 * Make sure that Drupal sends proper cache headers. To best test this, use the URL that Lagoon generates for bypassing the Varnish cache, \(locally in our Drupal example this is [http://nginx-drupal-example.docker.amazee.io](http://nginx-drupal-example.docker.amazee.io)\). Check for the `Cache-Control: max-age=900, public` header, where the `900` is what you configured in `$config['system.performance']['cache']['page']['max_age']`.
-* Make sure that the environment variable `VARNISH_BYPASS` is **not** set to `true` \(see `docker-compose.yml` and run `docker-compose up -d varnish` to make sure the environment variable is configured correctly\).
+* Make sure that the environment variable `VARNISH_BYPASS` is **not** set to `true` \(see `docker-compose.yml` and run `docker compose up -d varnish` to make sure the environment variable is configured correctly\).
 * If all fails, and before you flip your table \(╯°□°）╯︵ ┻━┻, talk to the Lagoon team, we're happy to help.
-<!-- markdown-link-check-enable -->
+<!-- markdown-link-check-enable -->

docs/applications/drupal/step-by-step-getting-drupal-ready-to-run-on-lagoon.md

@@ -45,29 +45,29 @@ x-environment:
 First, we need to build the defined images:
 
 ```bash title="Build images"
-docker-compose build
+docker compose build
 ```
 
 This will tell `docker-compose` to build the Docker images for all containers that have a `build:` definition in the `docker-compose.yml`. Usually for Drupal this is the case for the `cli`, `nginx` and `php` images. We do this because we want to run specific **build** commands \(like `composer install`\) or inject specific environment variables \(like `WEBROOT`\) into the images.
 
-Usually, building is not necessary every time you edit your Drupal code \(as the code is mounted into the containers from your host\), but rebuilding does not hurt. Plus, Lagoon will build the exact same Docker images during a deploy, so you can check that your build will also work during a deployment by just running `docker-compose build` again.
+Usually, building is not necessary every time you edit your Drupal code \(as the code is mounted into the containers from your host\), but rebuilding does not hurt. Plus, Lagoon will build the exact same Docker images during a deploy, so you can check that your build will also work during a deployment by just running `docker compose build` again.
 
 ## 4. Start Containers
 
 Now that the images are built, we can start the containers:
 
 ```bash title="Start containers"
-docker-compose up -d
+docker compose up -d
 ```
 
-This will bring up all containers. After the command is done, you can check with `docker-compose ps` to ensure that they are all fully up and have not crashed. If there is a problem, check the logs with `docker-compose logs -f [servicename]`.
+This will bring up all containers. After the command is done, you can check with `docker compose ps` to ensure that they are all fully up and have not crashed. If there is a problem, check the logs with `docker compose logs -f [servicename]`.
 
 ## 5. Rerun `composer install` \(for Composer projects only\)
 
 In a local development environment, you probably want all dependencies downloaded and installed, so connect to the `cli` container and run `composer install`:
 
 ```bash title="Run composer install in CLI"
-docker-compose exec cli bash
+docker compose exec cli bash
 composer install
 ```
 
@@ -85,7 +85,7 @@ If you get a 500 or similar error, make sure everything loaded properly with Com
 Finally it's time to install Drupal, but just before that we want to make sure everything works. We suggest using Drush for that:
 
 ```bash title="Drush status"
-docker-compose exec cli bash
+docker compose exec cli bash
 drush status
 ```
 

docs/concepts-advanced/base-images.md

@@ -122,7 +122,7 @@ There are several steps to the build process. Most of these are shared among the
 1. **Docker Login** - The Docker username, password, and URL for Harbor are passed to the Docker client.
 2. **Docker Build** - The `make images_build` step is run now, which will:
    1. Ensure that all environment variables are prepared for the build.
-   2. Run a `docker-compose build`. This will produce several new Docker images from the current Git branch.
+   2. Run a `docker compose build`. This will produce several new Docker images from the current Git branch.
 3. **Images Test** - This will run the `make images_test` target, which will differ depending on the images being tested. In most cases this is a very straightforward test to ensure that the images can be started and interacted with in some way \(installing Drupal, listing files, etc.\)
 4. **Docker Push** - This step runs the logic \(contained in the make target `images_publish`\) that will tag the images resulting from the **Docker Build** in Step 2 and push them to Harbor. This is described in more detail [elsewhere](base-images.md#step-4-building-the-new-base-images) in this guide.
 5. **Docker Clean Images** - Runs the make target `images_remove`, which simply deletes the newly built images from the Docker host now that they are in Harbor.