service/ci.md

@@ -84,6 +84,31 @@ Note that this feature was deprecated for a while but re-enabled. It
 is being [redesigned](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2797) to be more complete, as the above has
 important limitations.
 
+## Build Docker images with kaniko
+
+It is possible do build Docker images in our Gitlab CI without requiring user
+namespace support using [kaniko](https://github.com/GoogleContainerTools/kaniko).
+The Gitlab documentation [has examples](https://docs.gitlab.com/ee/ci/docker/using_kaniko.html)
+to get started with that task. There are some caveats, though, at the moment:
+
+1. One needs to pass `--force` to kaniko's executor or use a different
+   workaround due to a [bug in kaniko](https://github.com/GoogleContainerTools/kaniko/issues/1542)
+2. Pushing images to the Docker hub is not working out of the box. One rather
+   needs to [use the v1 endpoint](https://github.com/GoogleContainerTools/kaniko/issues/1209) at the moment due to a bug. Right now passing something like
+
+   ```
+   --destination "index.docker.io/gktpo/${CI_REGISTRY_IMAGE}:oldstable"
+   ```
+
+   to kaniko's executor does the trick for me.
+
+Additionally, as we want to build our images reproducibly, passing
+`--reproducible` to the executor is recommended as well.
+
+One final note: the Gitlab CI examples show that a debug image is used as a base
+image in Gitlab CI. That is important as the non-debug flavor does not come with
+a shell which is a requirement for Gitlab CI.
+
 ## FAQ
 
  * do runners have **network access**? **yes**, but that might
@@ -228,31 +253,6 @@ jobs it is currently running will be lost. Otherwise artifacts should
 be present on the GitLab server, so to recover a runner is as "simple"
 as creating a new one.
 
-## Build Docker images with kaniko
-
-It is possible do build Docker images in our Gitlab CI without requiring user
-namespace support using [kaniko](https://github.com/GoogleContainerTools/kaniko).
-The Gitlab documentation [has examples](https://docs.gitlab.com/ee/ci/docker/using_kaniko.html)
-to get started with that task. There are some caveats, though, at the moment:
-
-1. One needs to pass `--force` to kaniko's executor or use a different
-   workaround due to a [bug in kaniko](https://github.com/GoogleContainerTools/kaniko/issues/1542)
-2. Pushing images to the Docker hub is not working out of the box. One rather
-   needs to [use the v1 endpoint](https://github.com/GoogleContainerTools/kaniko/issues/1209) at the moment due to a bug. Right now passing something like
-
-   ```
-   --destination "index.docker.io/gktpo/${CI_REGISTRY_IMAGE}:oldstable"
-   ```
-
-   to kaniko's executor does the trick for me.
-
-Additionally, as we want to build our images reproducibly, passing
-`--reproducible` to the executor is recommended as well.
-
-One final note: the Gitlab CI examples show that a debug image is used as a base
-image in Gitlab CI. That is important as the non-debug flavor does not come with
-a shell which is a requirement for Gitlab CI.
-
 # Reference
 
 ## Installation