From 42cd73875cc513be7a67495444ae619bb9d0d7d5 Mon Sep 17 00:00:00 2001 From: David Glick Date: Tue, 22 Sep 2026 22:11:57 +0200 Subject: [PATCH] Fix links in deployment training --- docs/conf.py | 1 + docs/plone-deployment/build-deploy-gitlab.md | 2 +- docs/plone-deployment/cluster-vms.md | 2 +- docs/plone-deployment/community-resources.md | 2 +- docs/plone-deployment/cookieplone-extends.md | 2 +- docs/plone-deployment/deploy-challenges.md | 4 ++-- docs/plone-deployment/gitlab-runner-config.md | 6 +++--- docs/plone-deployment/intro.md | 6 +++--- docs/plone-deployment/reference/deploy-demo/4-registry.md | 2 +- docs/plone-deployment/reference/deploy-demo/6-operating.md | 2 +- docs/plone-deployment/reference/playcluster/6-gitlab.md | 4 ++-- 11 files changed, 17 insertions(+), 16 deletions(-) diff --git a/docs/conf.py b/docs/conf.py index afadee156..e05c5c460 100644 --- 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 index 082ff6bfb..7eb451309 100644 --- 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 index a1c2b2288..cf1b6e234 100644 --- 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 index 62e0533ac..95b730421 100644 --- 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 index 60c4265ba..2dabc0866 100644 --- 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 index 0732f609c..f4a229564 100644 --- 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 . 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 index 6999ef9c8..cc21ad14c 100644 --- 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 index f3a76a34e..8e4e860da 100644 --- 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 , and got a major update this year with interesting new features. +Cookieplone has reached traction in the community, has excellent documentation now at both and in its own documentation at , 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 index b829695a9..531231871 100644 --- 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 index 255488234..df20741b7 100644 --- 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 index 46c4d47e5..6abe48d45 100644 --- 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