fix(ci): switch back to GitLab's native Container Registry

Confirmed 2026-08-05 the project's Container Registry is now enabled
server-side (visible in the left sidebar under Deploy). That's strictly
better than the GHCR detour: $CI_REGISTRY/$CI_REGISTRY_USER/$CI_REGISTRY_PASSWORD
are predefined GitLab CI variables scoped to this project, so this needs
zero manually-created credentials (no GitHub PAT to hold in CI/CD variables).
This commit is contained in:
Bernd Rodler
2026-08-05 19:29:42 +02:00
parent 68d08dbae6
commit c71175e596
+23 -23
View File
@@ -34,15 +34,22 @@
# known amd64 microk8s clusters, not public multi-arch distribution (that's # known amd64 microk8s clusters, not public multi-arch distribution (that's
# what the GHCR release workflows are for, untouched by this file). # what the GHCR release workflows are for, untouched by this file).
# #
# Registry history (so nobody re-litigates this from scratch): GitLab's own
# Container Registry was the first choice, hit a dead end (registry_external_url
# alone didn't populate $CI_REGISTRY — see git history of this file around
# 2026-08-05 for the GHCR detour that followed), then got fixed server-side
# (gitlab_rails['registry_enabled'] confirmed set — the project's left sidebar
# now shows "Container Registry" under Deploy). Back on GitLab's native
# registry since then: it needs zero extra credentials (CI_REGISTRY_* are
# predefined GitLab CI variables, always present, scoped to this project
# only), which is strictly better than holding a GitHub PAT in GitLab CI/CD
# variables just to push images.
#
# Prerequisite this file assumes (documented in VNCMAIL-SETUP.md, not # Prerequisite this file assumes (documented in VNCMAIL-SETUP.md, not
# something this file can set up itself): # something this file can set up itself):
# - A GitHub PAT (write:packages) for ghcr.io/brvncde-dotcom as # - GitLab Container Registry enabled for this project (confirmed 2026-08-05
# $GITLAB_CI_GHCR_TOKEN, plus the matching GitHub username as # — "Container Registry" appears in the project's left sidebar under
# $GITLAB_CI_GHCR_USER — both masked/protected CI/CD variables. # Deploy / Packages and registries).
# GitLab's own Container Registry was tried first (registry_external_url
# alone isn't enough - gitlab_rails['registry_enabled'] = true is a
# separate config key that never got set, so CI_REGISTRY stayed empty);
# revisit switching back once that's actually confirmed working.
# - A GitLab Runner (any kind — no cluster access needed at all now). # - A GitLab Runner (any kind — no cluster access needed at all now).
# - Either "allow this job token to push to this project" enabled # - Either "allow this job token to push to this project" enabled
# (Settings → CI/CD → Job token permissions), OR a project access token # (Settings → CI/CD → Job token permissions), OR a project access token
@@ -60,17 +67,11 @@ stages:
- bump-prod - bump-prod
variables: variables:
# Reverted to GHCR 2026-08-05: GitLab's own Container Registry never made # GitLab's own registry, scoped to this project. $CI_REGISTRY_IMAGE is a
# it past "the registry service responds" - the Rails app itself never # predefined GitLab CI variable (populated automatically once the Container
# picked it up (no project-settings toggle appeared, CI_REGISTRY stayed # Registry is enabled for the project) — no manual image name to keep in
# empty even after the omnibus registry_external_url config), most likely # sync, no external credential.
# because gitlab_rails['registry_enabled'] = true was never separately IMAGE: $CI_REGISTRY_IMAGE
# set. That's a second, distinct config key from registry_external_url -
# revisit switching back once/if that's actually confirmed on the server.
# Same image name the sandbox already ran before this pipeline existed
# (confirmed public - no imagePullSecrets needed, see
# base/deployment.yaml's history), so this is a revert, not a new risk.
IMAGE: ghcr.io/brvncde-dotcom/vncmail-plus-dev
GIT_STRATEGY: clone GIT_STRATEGY: clone
# --------------------------------------------------------------------------- # ---------------------------------------------------------------------------
@@ -102,11 +103,10 @@ build:
rules: rules:
- if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "dev"' - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "dev"'
before_script: before_script:
# GHCR needs a real GitHub PAT (write:packages) as GITLAB_CI_GHCR_TOKEN, # $CI_REGISTRY / $CI_REGISTRY_USER / $CI_REGISTRY_PASSWORD are predefined
# plus GITLAB_CI_GHCR_USER (the GitHub username the PAT belongs to) — # GitLab CI variables — populated automatically now that this project's
# both as masked/protected CI/CD variables. Nothing GitLab-native can # Container Registry is enabled. No CI/CD variable to create by hand.
# substitute here; a GitHub credential has to come from GitHub. - echo "$CI_REGISTRY_PASSWORD" | docker login "$CI_REGISTRY" -u "$CI_REGISTRY_USER" --password-stdin
- echo "$GITLAB_CI_GHCR_TOKEN" | docker login ghcr.io -u "$GITLAB_CI_GHCR_USER" --password-stdin
script: script:
- docker build --build-arg GIT_COMMIT=$CI_COMMIT_SHA -t "$IMAGE:sha-$CI_COMMIT_SHORT_SHA" -t "$IMAGE:dev-latest" . - 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:sha-$CI_COMMIT_SHORT_SHA"