We use the [`docs-gitlab-com-builder.Dockerfile`](https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com/-/blob/main/dockerfiles/docs-gitlab-com-builder.Dockerfile?ref_type=heads) Docker image for compiling the website on the pipeline. This image is based on [`hugomods/hugo:node-lts`](https://docker.hugomods.com/docs/tags/#node-lts), which includes Hugo itself and node.js. We use `apk` to install whatever version of Go is available to the `hugomods` image. This has been working OK so far, but with this setup, the `hugomods` image defines the versions of Go and Node we get in our build job. These haven't always matched the versions we're using for local development and in test jobs (as found in https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com/-/merge_requests/545#note_2433315488, when we had v1.24 for local dev, but not in the build job). If we're bothering to pin versions at all, we should make sure that the versions used for our prod build match up with everything else. Since we're already maintaining our own build image, using the `hugomods` base doesn't save us much in terms of maintenance efforts, it just adds another layer of abstraction. ## Done when - `docs-gitlab-com-builder.Dockerfile` builds from a more minimal base image (probably Alpine stable since we use this elsewhere) - `docs-gitlab-com-builder.Dockerfile` runs versions the same versions of Go and Node that are used for local development and in CI test jobs