vuer_build/build.sh never publishes — the legacy Harbor gap

vuer_build/build.sh — the legacy partner build path — contains no docker push and no docker login. It builds and tags images locally and can export them as .tar, and that is where it stops. How those images actually reach harbor.techteamer.com is not documented in any file read so far. Established 2026-08-11.

Open question, not a guess — and it sits on a live release

The publish mechanism for the legacy path (manual docker push? a separate script? an ops runbook outside the repo?) has not been found. Do not assume build.sh completes a release. CIB is on the legacy path, so this gap is load-bearing for the CIB release currently in flight.

For Agents

• Verified how: grep -n push build.sh in vuer_build → zero hits for docker push / docker login. Sourced from facekom-v2 build-deploy-release §3.2 + §7 and vuer_build §10.
• build.sh version: 0.4.1. sign-partner.sh version: 0.1.1.
• If you need to know whether a legacy partner image is published, you cannot answer it from this repo. Ask the operator.

What build.sh actually does

Builds, tags locally, and optionally packs. Image naming:

harbor.techteamer.com/${PROJECT_NAME}/<svc>:${VUER_VERSION}.${VUER_BUILD_NUMBER}-${SECURITY_NUMBER}

Common infra goes to harbor.techteamer.com/vuer-common/<svc>:<version>.<build>-<COMMON_SECURITY_NUMBER>. The harbor.techteamer.com/… prefix is only a tag — nothing in the script contacts the registry. Images can be exported as .tar into the customer ZIP (--build_package).

Signing is not publishing. sign-partner.sh (v0.1.1) wraps cosign:

cosign sign --key cosign.key \
  --annotations 'Signer=Facekom Kft' \
  --annotations 'Signer_URL=https://facekom.net' <image_tag>

-i signs a single image, -t signs everything in a tag list. Signing an image says nothing about whether it was pushed.

Contrast: the modern path does publish

	legacy vuer_build	modern vuer-release
Driver	bash build.sh on a workstation	external release-tool + GitHub Actions (.github/workflows/autobuild.yml)
Publish	none in the script	release-tool publish push
Registry auth	absent	release-tool publish login with secrets.HARBOR_USER / secrets.HARBOR_SECRET → DOCKER_REGISTRY_USERNAME / DOCKER_REGISTRY_PASSWORD
Source auth	host ssh-agent + per-service base/<svc>/github.key	secrets.RELEASE_PAT

Partner migrations off the legacy path onto vuer-release are tracked in FKITDEV-8344-vuer-release-migration-batch; the cut procedure for the modern path is vuer-release-cut-recipe.

Why this matters right now

CIB 1.9.11.102 is on the legacy path and is one of three releases in flight (alongside NÚSZ .48 and Generali .19, both modern). Build path per partner is recorded in client-registry.

Version discrepancy — RESOLVED 2026-08-11

An earlier draft of this note flagged a conflict between .101 and .102. Settled by git ls-remote --tags: cib-1.9.11.101 already exists in both vuer_oss and vuer_css (102 tags each), so .101 is the shipped version and the in-flight target is .102 — matching client-registry and FKITDEV-9197, and matching the live+1 pattern of the other two releases (both also pre-tag).

Worth keeping: portal_css holds no cib-1.9.11.* tags at all. CIB genuinely ships portal_css — that is where FKITDEV-9197 broke — but it runs its own lifecycle (Travis, own audit gate) and never carries the partner version. “Which repos a partner ships” and “which repos get the release tag” are two different lists.

The standing rule stands regardless: resolve a partner’s version only from its open ASSCIB Assistance Type: Release issue or git ls-remote --tags — never from a note, never from conversation.

Two other vuer_build traps

build.sh -l/--list-partners is broken

It does cd partners/ (build.sh:447) but the real directory is partner/ (singular). The flag errors out. Use ls partner/ directly — 39 partner dirs.

Builds fail without an operator-supplied github.key

Base Dockerfiles copy base/<svc>/github.key → /root/.ssh/id_rsa to clone the private app repos. *.key is gitignored, so nothing is committed — the operator must drop their own key in (README.md:22-28). A fresh clone cannot build.

Base OS is branch-dependent

Any “vuer_build is UBIN” claim is only true of a branch:

Branch	Base OS
main	UBI9
feature/FKITDEV-8868	UBI8
feature/FKITDEV-8252-ubi10	UBI10

Always check which branch you are on before reasoning about the image base. See FKITDEV-8252 for the UBI10 migration and FKITDEV-8868.

Related

• facekom-v2 build-deploy-release — §3.2 legacy path, §7 registry, §9 gotchas (source)
• vuer_build — repo survey (source)
• release-process · release-pipeline-automation-spec · release-automation-design
• vuer-release-cut-recipe · client-registry · FKITDEV-8344-vuer-release-migration-batch
• dev-build-host — where legacy builds actually run (fk-dev)
• facekom-test-tiers — the other half of the release-readiness gap