diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 30955b26..4ae76c51 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -89,44 +89,49 @@ verify: - npm run test:translations - npm run build # test:integration is deliberately NOT here — it spins up a real Stalwart - # fixture via docker-compose (Docker-in-Docker), heavier than a fast MR - # gate should be. Candidate for a separate scheduled job, not a blocker. + # fixture via docker-compose, which needs an actual Docker daemon this + # runner's Kubernetes executor doesn't provide without privileged mode + # (see the build job below). Candidate for a separate scheduled job on a + # differently-configured runner, not a blocker on every MR. # --------------------------------------------------------------------------- # build — push to dev only. Builds once; main never rebuilds (see header). # --------------------------------------------------------------------------- build: stage: build - image: docker:27-cli - services: - - docker:27-dind + # Kaniko builds OCI images without a Docker daemon, so it needs neither a + # dind service nor a privileged pod — GitLab's own recommended approach + # for the Kubernetes executor specifically. The docker:27-cli + dind + # combination that was here before this got as far as a successful + # $CI_REGISTRY login, then failed every way it was pointed + # (unix:///var/run/docker.sock, tcp://docker:2375, tcp://localhost:2375): + # the dind container itself was never actually listening, which on this + # executor means it needs `privileged: true` in the runner's own + # config.toml — a cluster/GitLab-admin setting outside this file's + # control. Kaniko sidesteps that requirement entirely rather than chasing + # runner permissions further, and is also the safer default on a shared + # cluster (no privileged containers at all). + image: + name: gcr.io/kaniko-project/executor:v1.23.2-debug + entrypoint: [""] rules: - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "dev"' - variables: - # docker:27-dind defaults to TLS on :2376 with certs under - # /certs/client, which this client image never mounts — the dind - # service comes up fine but the docker:27-cli image can't find it, - # surfacing as "Cannot connect to the Docker daemon at - # unix:///var/run/docker.sock" even though $CI_REGISTRY login already - # succeeded (that's a separate connection, straight to the registry, - # not through the daemon). DOCKER_TLS_CERTDIR="" disables that TLS - # requirement. Host is `localhost`, not the service alias `docker` — - # this runner uses GitLab's Kubernetes executor, where every container - # in a job shares one pod's network namespace, unlike the Docker - # executor's bridge network (where the service-name alias is how you'd - # reach it instead). Confirmed from the job log: pod names like - # runner-uncqet63-project-499-concurrent-* are Kubernetes-executor pods. - DOCKER_HOST: tcp://localhost:2375 - DOCKER_TLS_CERTDIR: "" - before_script: - # $CI_REGISTRY / $CI_REGISTRY_USER / $CI_REGISTRY_PASSWORD are predefined - # GitLab CI variables — populated automatically now that this project's - # Container Registry is enabled. No CI/CD variable to create by hand. - - echo "$CI_REGISTRY_PASSWORD" | docker login "$CI_REGISTRY" -u "$CI_REGISTRY_USER" --password-stdin script: - - docker build --build-arg GIT_COMMIT=$CI_COMMIT_SHA -t "$IMAGE:sha-$CI_COMMIT_SHORT_SHA" -t "$IMAGE:dev-latest" . - - docker push "$IMAGE:sha-$CI_COMMIT_SHORT_SHA" - - docker push "$IMAGE:dev-latest" + # $CI_REGISTRY / $CI_REGISTRY_USER / $CI_REGISTRY_PASSWORD are predefined + # GitLab CI variables, populated automatically now that this project's + # Container Registry is enabled — same credentials the old docker-login + # step already proved work, just handed to kaniko's own config.json + # instead of a daemon's. + - mkdir -p /kaniko/.docker + - | + echo "{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(printf '%s:%s' "$CI_REGISTRY_USER" "$CI_REGISTRY_PASSWORD" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json + - > + /kaniko/executor + --context "$CI_PROJECT_DIR" + --dockerfile "$CI_PROJECT_DIR/Dockerfile" + --build-arg GIT_COMMIT=$CI_COMMIT_SHA + --destination "$IMAGE:sha-$CI_COMMIT_SHORT_SHA" + --destination "$IMAGE:dev-latest" # --------------------------------------------------------------------------- # bump-dev — no cluster access. Commits the just-built tag into the overlay