plone · davisagli · Sep 22, 2026 · stevepiercy · Sep 22, 2026 · davisagli
diff --git a/docs/conf.py b/docs/conf.py
@@ -75,6 +75,7 @@
     r"https://www.npmjs.com/",  # tests say 403 Server Error, but manually they work
     r"https://www.merriam-webster.com/",  # tests say 403 Server Error, but manually they work
     r"https://www.linode.com/.*",  # tests say 500 Server Error, but manually they work
+    r"https://(.*.)?playcluster.plone.org.*",  # we don't commit to keeping this running all the time
     # Ignore static file downloads
     r"^/_static/",
     r"^/_images/",

diff --git a/docs/plone-deployment/build-deploy-gitlab.md b/docs/plone-deployment/build-deploy-gitlab.md
@@ -183,7 +183,7 @@ The simplest way: {menuselection}`Deploy --> Environments --> production`, and *
 
 You can also run a pipeline on `main` with the variable `IMAGE_TAG` set to the tag you want.
 The build jobs are skipped in such a pipeline, on purpose: building would push today's code under the old tag.
-On GitLab.com, running a pipeline with variables has to be allowed first, under {menuselection}`Settings --> CI/CD --> Variables`.
+On `gitlab.com`, running a pipeline with variables has to be allowed first, under {menuselection}`Settings --> CI/CD --> Variables`.
 
 ## When it breaks
 

diff --git a/docs/plone-deployment/cluster-vms.md b/docs/plone-deployment/cluster-vms.md
@@ -228,7 +228,7 @@ Ansible does the rest: it installs the runner, registers it with that token, and
 
 Register the runner on a GitLab *group*, rather than on a single project.
 A group runner picks up jobs from every project in that group, so a new project can use the cluster without any extra setup.
-For this training that group is [plone-training1](https://gitlab.com/plone-training1) on GitLab.com; any group on your own GitLab instance works the same way.
+For this training that group is [plone-training1](https://gitlab.com/plone-training1) on `gitlab.com`; any group on your own GitLab instance works the same way.
 
 1. In the group, go to {menuselection}`Build --> Runners`, and choose {guilabel}`New group runner`.
 2. Under **Tags**, enter `docker` and `deploy`.

diff --git a/docs/plone-deployment/community-resources.md b/docs/plone-deployment/community-resources.md
@@ -66,7 +66,7 @@ new host name.
 
 ## Tools the pipeline reuses
 
-[repoplone](https://pypi.org/project/repoplone/)
+[repoplone](https://pypi.org/project/RepoPlone/)
 : Reads `repository.toml` and reports the project's Python, Plone and Volto versions. The pipeline's
   first job asks it, so no version is written down twice.
 

diff --git a/docs/plone-deployment/cookieplone-extends.md b/docs/plone-deployment/cookieplone-extends.md
@@ -19,7 +19,7 @@ Afterwards we look at how the setup could become something you generate instead
 
 ### What you get for free
 
-Each group gets its own project in the `plone-training1` group on GitLab.com, as a copy of `training-deployment-gitlabdeploy`.
+Each group gets its own project in the `plone-training1` group on `gitlab.com`, as a copy of `training-deployment-gitlabdeploy`.
 A lot comes with the GitLab group, without any setup in the new project:
 
 - **The runner** on `play4` is a group runner, so it picks up the new project's jobs.

diff --git a/docs/plone-deployment/deploy-challenges.md b/docs/plone-deployment/deploy-challenges.md
@@ -11,9 +11,9 @@ myst:
 
 # Deploy challenges in real life
 
-This is a small chapter to give a bit more background on the 'why show the end result' in this training with 2 repos and deviate from the deployment training on 2025.training.plone.org. It should also help the reader to maybe go to that training instead.
+This is a small chapter to give a bit more background on the 'why show the end result' in this training with 2 repos and deviate from the deployment training at <https://2025.training.plone.org>. It should also help the reader to maybe go to that training instead.
-This is a small chapter to give a bit more background on the 'why show the end result' in this training with 2 repos and deviate from the deployment training at <https://2025.training.plone.org>. It should also help the reader to maybe go to that training instead.
+This is a small chapter to give a bit more background on the 'why show the end result' in this training with 2 repos and deviate from the deployment training at https://2025.training.plone.org. It should also help the reader to maybe go to that training instead.
-This is a small chapter to give a bit more background on the 'why show the end result' in this training with 2 repos and deviate from the deployment training at <https://2025.training.plone.org>. It should also help the reader to maybe go to that training instead.
+This is a small chapter to give a bit more background on the 'why show the end result' in this training with 2 repos and deviate from the deployment training at https://2025.training.plone.org. It should also help the reader to maybe go to that training instead.
 
-The 2025 training is still better suited to show a clean 'lab setup' for your first deployment to a containerised hosting setup. We could update the training to offer a separate 'get your own VM' instead of using a trainer provided tangrama.com.br setup.  One of the realities of mid 2026 is that a VM with 8 GB RAM costs more than 40 euro/month, compared to 7 euro/month in 2025.
+The 2025 training is still better suited to show a clean 'lab setup' for your first deployment to a containerised hosting setup. We could update the training to offer a separate 'get your own VM' instead of using a trainer provided `tangrama.com.br` setup.  One of the realities of mid 2026 is that a VM with 8 GB RAM costs more than 40 euro/month, compared to 7 euro/month in 2025.
 
 A first source of extra challenges comes from going to a multi-node swarm cluster, where the backend/frontend runs on separate worker nodes, and we should place the postgresql container on a fixed 'storage' node.  These are essential multi-node containerisation skills to teach.
 

diff --git a/docs/plone-deployment/gitlab-runner-config.md b/docs/plone-deployment/gitlab-runner-config.md
@@ -84,9 +84,9 @@ In that case, set the deployment variables on each project instead.
 
 **`REGISTRY_IMAGE_PREFIX` must not be protected.**
 The pipeline's first job, `config`, runs in every pipeline, including merge request pipelines on unprotected branches, and they do not receive protected variables.
-On GitLab.com, the job then does not fail.
-It quietly falls back to GitLab.com's own container registry, which is always enabled there.
-The build pushes to GitLab.com, while the deploy looks for the images in your own registry.
+On `gitlab.com`, the job then does not fail.
+It quietly falls back to `gitlab.com`'s own container registry, which is always enabled there.
+The build pushes to `gitlab.com`, while the deploy looks for the images in your own registry.
 
 **`$CI_PROJECT_PATH` is resolved by the pipeline, not by GitLab.**
 The one group variable, `registry.playcluster.plone.org/$CI_PROJECT_PATH`, gives every project its own place in the registry, such as `plone-training1/my-site`.

diff --git a/docs/plone-deployment/intro.md b/docs/plone-deployment/intro.md
@@ -41,9 +41,9 @@ This is the part that you don't see in public repositories/setups, as the setup
 
 The Plone Community doesn't have the resources to support and maintain 'production grade' fully abstracted scaffolding in cookieplone for all the combinations of these required tooling, CI/CD solution, and Server Deployments. This training is an experiment where we begin with a specific end result in mind: an autonomous training cluster that can lead to a production deployment.
 
-## GitLab.com
+## `gitlab.com`
 
-We will use gitlab.com as a hosted service so that we have exposure, and don't need to set up a full GitLab locally hosted instance. If time permits, I also want to offer you to experiment in the afternoon with deploying a project to our demo cluster. But you can also host GitLab yourself. From there on everything else (ci/cd, deployment) is running on systems you host and manage yourself.
+We will use `gitlab.com` as a hosted service so that we have exposure, and don't need to set up a full GitLab locally hosted instance. If time permits, I also want to offer you to experiment in the afternoon with deploying a project to our demo cluster. But you can also host GitLab yourself. From there on everything else (ci/cd, deployment) is running on systems you host and manage yourself.
 
 ## Kubernetes
 
@@ -56,7 +56,7 @@ Working at a Plone integrator (kitconcept), we got a request in 2026 to organise
 
 A secondary wish was to have a full GitLab CI/CD setup documented. With GitLab's option to self-host, and adding a bit more digital autonomy on the runner, a fully 'stand alone' Plone deployment pipeline was the new goal.
 
-Cookieplone has reached traction in the community, has excellent documentation now on both docs.plone.org and on its own documentation at <https://plone.github.io/cookieplone/>, and got a major update this year with interesting new features.
+Cookieplone has reached traction in the community, has excellent documentation now at both <https://6.docs.plone.org/> and in its own documentation at <https://plone.github.io/cookieplone/>, and got a major update this year with interesting new features.
-Cookieplone has reached traction in the community, has excellent documentation now at both <https://6.docs.plone.org/> and in its own documentation at <https://plone.github.io/cookieplone/>, and got a major update this year with interesting new features.
+Cookieplone has reached traction in the community, has excellent documentation now at both https://6.docs.plone.org/ and in its own documentation at https://plone.github.io/cookieplone/, and got a major update this year with interesting new features.
-Cookieplone has reached traction in the community, has excellent documentation now at both <https://6.docs.plone.org/> and in its own documentation at <https://plone.github.io/cookieplone/>, and got a major update this year with interesting new features.
+Cookieplone has reached traction in the community, has excellent documentation now at both https://6.docs.plone.org/ and in its own documentation at https://plone.github.io/cookieplone/, and got a major update this year with interesting new features.
 
 Combined with the insight that we have a grey area between local development setup and 'serious' deployment setup, the idea was to do a 'show and tell' training instead of trying to provide an interactive training this year.
 
diff --git a/docs/plone-deployment/reference/deploy-demo/4-registry.md b/docs/plone-deployment/reference/deploy-demo/4-registry.md
@@ -101,7 +101,7 @@ through one. That is why credential selection happens in the shell.
 ```
 
 Here, `REGISTRY_IMAGE_PREFIX` is set, to use the cluster's own registry. On
-GitLab.com the built-in registry is always enabled, and that makes one mistake
+`gitlab.com` the built-in registry is always enabled, and that makes one mistake
 quiet: if `REGISTRY_IMAGE_PREFIX` is missing from a pipeline — typically because
 it was marked *Protected* and the pipeline runs on an unprotected branch — the
 `config` job does not fail. It falls back to GitLab's registry, the build pushes

diff --git a/docs/plone-deployment/reference/deploy-demo/6-operating.md b/docs/plone-deployment/reference/deploy-demo/6-operating.md
@@ -181,7 +181,7 @@ code and push it under the old tag, the "rollback" would deploy today's code,
 and the old image would lose its tag.
 
 ```{note}
-On GitLab.com, new projects do not allow pipeline variables: the form under
+On `gitlab.com`, new projects do not allow pipeline variables: the form under
 {menuselection}`Run pipeline` then shows no variables section at all. To allow
 them, set {menuselection}`Settings --> CI/CD --> Variables --> Minimum role to use pipeline variables`
 to *Maintainer*. The first way, **Re-deploy** from the environment, works

diff --git a/docs/plone-deployment/reference/playcluster/6-gitlab.md b/docs/plone-deployment/reference/playcluster/6-gitlab.md
@@ -84,9 +84,9 @@ deployment variables per project instead.
 
 **`REGISTRY_IMAGE_PREFIX` must not be protected.** The first job of the pipeline
 runs in every pipeline, including merge requests on unprotected branches, which
-do not receive protected variables. On GitLab.com the pipeline then does not
+do not receive protected variables. On `gitlab.com` the pipeline then does not
 fail: it falls back to GitLab's own container registry, which is always enabled
-there. Images get pushed to GitLab.com while the deploy looks for them in your
+there. Images get pushed to `gitlab.com` while the deploy looks for them in your
 registry.
 
 **`$CI_PROJECT_PATH` is resolved by the pipeline, not by GitLab.** One group