Levandor

Build, Deployment & Release from Source (vuer_build · vuer_docker · vuer-release)

16 min read

Build, Deployment & Release from Source

How FaceKom (“Vuer”) application source becomes versioned, tagged Docker images and shippable artifacts. Three repos own this, and they represent three generations of the same pipeline:

RepoRoleChecked-out branch (survey time)Base-OS era
vuer-release (vuer-release)Current release source-of-truth + image factory, driven by an external release-tool CLI + GitHub Actionsfeature/FKITDEV-8252-ubi10 (HEAD 9a54612)UBI10 (master = UBI9)
vuer_build (vuer_build)Legacy/parallel bash+compose build orchestration + customer ZIP packagerfeature/FKITDEV-8868 (HEAD 341a553)UBI8 (main = UBI9; an FKITDEV-8252-ubi10 branch = UBI10)
vuer_docker (vuer_docker)Local dev + CI/test environment (compose), also an image factorydevel (HEAD 640d853)mixed: UBI9 Node svcs, UBI8 + Ubuntu others

This page is a cross-repo synthesis. Each repo has a deeper standalone note.

Read vuer-release, vuer_build, vuer_docker for the per-repo detail (process model, configs, scripts). This note focuses on the build/deploy/release mechanics + Dockerfile/base-image inventory + the active FKITDEV branches, and corrects one base-OS claim in the older notes (see §2 warning).

See also: architecture-overview · customization-architecture · customization-branch-catalog · FKITDEV-8252-oracle-ol10-memo · INDEX

1. The two build pipelines (and one dev env)

There are two distinct, non-interchangeable build systems, plus the dev-env image factory:

A. vuer-release — current pipeline (CLI + CI, declarative)

release.json descriptors + per-component Dockerfiles, built/published by the external release-tool binary (TechTeamer/vuer-release-cli) invoked from a GitHub Actions workflow on a self-hosted runner (README.md:1-28; .github/workflows/autobuild.yml). The repo holds no build logic of its own — release-tool does gen/build/publish. (README.md:8-15.)

B. vuer_build — legacy pipeline (bash + docker compose, imperative)

Root bash drivers (build.sh, build-openshift.sh, sign-partner.sh) + docker-compose-base.yml / docker-compose-common.yml + per-partner partner/<name>/docker-compose.yml. build.sh clones source at a git tag, runs docker compose build, optionally runs a Node packager to produce a customer ZIP. (build.sh:1-554, README.md.) README is Hungarian.

Relationship between A and B

Both target the same registry (harbor.techteamer.com) and the same product. vuer-release is the newer, descriptor-driven model (per-partner projects/); vuer_build is the older imperative model (per-partner partner/). The packager in vuer_build (create-build-package.js) still references vuer_build@main (buildcode) + vuer_docker@devel (dev env) when assembling a customer ZIP, so vuer_build remains the source-handover tool even as vuer-release owns CI image builds. The exact handoff between the two is not encoded in any file read — treat as two coexisting systems. (Unverified gap.)

C. vuer_docker — dev & CI/test environment

Compose files (dev.yml, vuer-oss.yml, …) + bin/vuer.sh CLI stand up the full stack locally against host-mounted source. Also builds the CI testenv image. Not a release pipeline. (README.md devel; bin/vuer.sh.) See vuer_docker.

2. Dockerfile inventory & base images

Counts are tracked Dockerfiles at the checked-out HEAD (git ls-tree -r HEAD | grep -i Dockerfile).

Repo (branch)Dockerfile countFirst-party base images
vuer-release (feature/FKITDEV-8252-ubi10)48ubi10/ubi-minimal (+ ubi10/openjdk-21 builder; postgres:*-bookworm)
vuer_build (feature/FKITDEV-8868)119ubi8/ubi-minimal (+ postgres:*-bookworm)
vuer_docker (devel)18ubi9/ubi-minimal (Node svcs) + ubi8/ubi-minimal + ubuntu:* + mssql/server:2019

CORRECTION to the older repo notes: vuer_build base OS is branch-dependent, and main is UBI9 (not UBI8)

The vuer_build note states base images are UBI8 “throughout”. Verified against git, the real picture is three base-OS lines on three branches (FROM of base/vuer_oss/Dockerfile):

  • main → registry.access.redhat.com/ubi9/ubi-minimal (HEAD 341a553’s parent line is UBI9)
  • feature/FKITDEV-8868 (currently checked out) → ubi8/ubi-minimal — the commit msg literally says “add janus admin api config to Ubi8 branch” (HEAD 341a553)
  • feature/FKITDEV-8252-ubi10 → ubi10/ubi-minimal (adds a new nginx-module-builder stage) So the “UBI8” claim is only true for the FKITDEV-8868 working tree, which is what was checked out when the note was written. Verified: git -C vuer_build show {main,feature/FKITDEV-8868,feature/FKITDEV-8252-ubi10}:base/vuer_oss/Dockerfile | grep FROM.

2.1 vuer-release base images (48 Dockerfiles)

Verified git ls-tree -r HEAD | grep Dockerfile + FROM extraction.

  • 11 base components under base/components/<comp>/Dockerfile: vuer_oss, vuer_css, janus, turn, rabbitmq, postgresql, clamav, pdfservice, resource-manager, nyilvantarto_scraper, vuer_cv (vuer_cv is definition-only — NO Dockerfile, just component_env_values.json). So base/components has 10 Dockerfiles, not 11.
  • 1 bundle image: bundle-image/Dockerfile (FROM ubi10/ubi-minimal:latest).
  • 37 project overrides under projects/<partner>/components/<comp>/Dockerfile, almost all FROM $BASE_COMPONENT_IMAGE_TAG (the base image just built; supplied by release-tool). Exception: unicredit-srb components janus/portal_css/rabbitmq/turn use full FROM harbor.techteamer.com/... refs (older-style), while its vuer_oss/vuer_css use $BASE_COMPONENT_IMAGE_TAG.

Base FROM lines on this branch (all UBI10 unless noted):

  • vuer_oss: 2-stage ubi10/ubi-minimal (oss-janus-compile → build-vuer-oss).
  • vuer_css, resource-manager, nyilvantarto_scraper, turn, rabbitmq, clamav: ubi10/ubi-minimal.
  • janus: 2-stage ubi10/ubi-minimal (janus-compile → build-janus).
  • pdfservice: builder ubi10/openjdk-21 → runtime ubi10/ubi-minimal.
  • postgresql: postgres:${VERSION}-bookworm (Debian, not UBI — rootless-patched).

2.2 vuer_build base images (119 Dockerfiles)

Verified FROM extraction on feature/FKITDEV-8868.

  • 4 base base/{vuer_oss,vuer_css,portal_css,janus}/Dockerfile → ubi8/ubi-minimal (multi-stage; vuer_oss and janus add a januscompilestage).
  • 8 common common/{rabbitmq,turn,clamav,postgresql}{,-base}/Dockerfile: the *-base images are ubi8/ubi-minimal (postgresql-base = postgres:${POSTGRESQL_VERSION_NUMBER}-bookworm); the non--base images FROM the just-built harbor.techteamer.com/vuer-common/<svc>-base:....
  • 1 packaging packaging/Dockerfile → ubi8/ubi-minimal (installs nodejs + yarn gcc-c++ make bzip2 fontconfig, runs yarn install).
  • 1 dap partner/dap/dap_demo_partner/Dockerfile → ubi8/ubi-minimal (multi-stage demo partner).
  • ~105 partner overrides partner/<name>/<svc>/Dockerfile: every one FROM harbor.techteamer.com/${PROJECT_NAME}/<svc>:${VERSION}.${BUILD}-${SECURITY} (or vuer-common/<svc> / <svc>-base for the common infra). I.e. partner Dockerfiles layer config on top of base/common images, they do not set an OS base. 39 partner dirs (+ a .gitkeep; verified git ls-tree origin/main:partner = 39 trees + 1 blob; catalogued in vuer_build §6 / customization-branch-catalog).

2.3 vuer_docker base images (18 Dockerfiles, devel)

Verified FROM extraction. Mixed bases — the older note’s “UBI9” is accurate only for the Node services:

BaseDockerfiles
ubi9/ubi-minimalvuer_oss, vuer_css, portal_css, esign_oss, esign_css, facekom_library, rabbitmq
ubi8/ubi-minimalavast, nyilvantarto, pdfservice
ubuntu:bionicclamav, janus, janus/janus_dev.Dockerfile, turn
ubuntu:jammypostgresql
ubuntu:focaltestenv (2-stage januscompilestage)
mcr.microsoft.com/mssql/server:2019-latestmssql
harbor.techteamer.com/${PROJECT_NAME}/vuer_cv:...vuer_cv_dev (builder FROM prebuilt CV image)

Node version differs per pipeline

vuer-release bakes Node 22 (base/default_env_values.json:7 NODE_VERSION: 22). vuer_build packaging image installs Node 20 (packaging/Dockerfile pulls the NodeSource pub_20.x/el/8 release RPM, then microdnf install nodejs); its core base app images (vuer_oss/vuer_css/portal_css) install Node 22 — the Dockerfiles still COPY/RUN tools/install-nodejs-22.sh on FKITDEV-8868 (verified git grep install-nodejs HEAD -- '*Dockerfile*'), so the deployed app runtime stays Node 22. FKITDEV-8868 added a Node-20 variant (install-nodejs-20.sh) alongside the existing install-nodejs-22.sh and uses it only for the dap demo partner — it did not repoint the core app images (see §6). vuer_docker devel bakes Node 24 (install/install-nodejs-24.sh, .env not version-pinning node). These are independent toolchains.

3. How images are built, tagged & published

3.1 vuer-release (CI/CLI) — the current path

CI workflow .github/workflows/autobuild.yml (read in full):

  • Trigger: push of a tag matching *@* AND a changed path projects/*/release/*/release.json or base/release/*/release.json. Tag format is load-bearing: <name>@<version>, e.g. nusz@12, base@6.
  • parse_tag job (runs-on: [self-hosted, docker]): splits the tag on the first @ → project_name + release_version. Empty version → fail.
  • build job (runs-on: [self-hosted, docker]):
    1. actions/checkout@v4.
    2. Set Token — writes ~/.git-credentials with secrets.RELEASE_PAT (to clone private component source repos).
    3. Download Release CLI — curls the release_tool asset from the latest GitHub release of TechTeamer/vuer-release-cli (auth secrets.RELEASE_PAT), chmod +x, adds to $GITHUB_PATH as release-tool.
    4. Configure — release-tool --offline config set release_repo_path ${{ github.workspace }}.
    5. Build (branches on base@ prefix):
      • base: release-tool --offline gen base -r <ver> → ... build base -r <ver>.
      • project: release-tool --offline gen project -p <name> -r <ver> → ... build project ....
    6. Publish (branches on base@): release-tool --offline publish login {base|project} ... → ... publish push ..., with env DOCKER_REGISTRY_USERNAME=secrets.HARBOR_USER, DOCKER_REGISTRY_PASSWORD=secrets.HARBOR_SECRET.
    7. Built Image List — reads build/image/<listfile>, runs docker images <image> per line → build/image/image_list.log.
    8. Upload artifact actions/upload-artifact@v4 — image_list.log + build/log/*.log as <project>-<version>-release-artifact.

All gen/build/publish logic lives in the external CLI, NOT this repo

Env-value precedence/merging, source-package fetching (cloning each component at its VERSION, packaging $SOURCE.tar.gz, bind-mounting as the sourcecode BuildKit context), and compose generation are inside TechTeamer/vuer-release-cli (not present locally). Documented only via observable inputs (release.json, Dockerfiles, the CLI calls above). (Unverified internal logic.)

Local release (developer): download the release_tool binary, run it → it generates release.json, commits it, pushes the tag → CI fires. (README.md:12-28.)

Image tag / registry: from base/default_env_values.json → DOCKER_REGISTRY=harbor.techteamer.com, GIT_REMOTE_ORG=https://github.com/TechTeamer, SECURITY_NUMBER=20250121, UID/GID=1000, NODE_VERSION=22, RUNTIME_ENV=docker. Per-component TAG/VERSION/BUILD_NUMBER come from release.json COMPONENT_LIST (e.g. nusz/12 vuer_oss VERSION 1.9.11.46, TAG nusz-1.9.11.46). The final registry path convention (built by release-tool) matches the partner overrides’ harbor.techteamer.com/<project>/<svc>:<version>.<build>-<security>.

3.2 vuer_build (bash) — the legacy path

build.sh (v 0.4.1):

  • Tag-derivation (build.sh:1-58): from -b <VUER_TAG> it computes VUER_TAG_NAME (tag minus trailing -N.N), VUER_VERSION (grep -Po '\d+\.\d+\.\d+'), VUER_BUILD_NUMBER (last dotted segment). -bv N appends _N to the build number (rebuild a tag with a new image id). Same scheme for PORTAL_*.
  • Build stages, in order (build.sh:177-553): init → init_build_pack → base_build → optional common_build → custom_build (if partner/<TAG_NAME>/docker-compose.yml exists) → build_pack (if --build_package) → cleanup.
  • Build mechanism: docker compose -f docker-compose-base.yml build --force-rm --no-cache <service> (base; build.sh:194), docker compose -f docker-compose-common.yml build ... <svc>-base then <svc> (common; :242-247), docker compose build ... inside the partner dir (custom; :219). DOCKER_BUILDKIT=1.
  • Image naming (docker-compose-base.yml, build.sh:157-160): harbor.techteamer.com/${PROJECT_NAME}/<svc>:${VUER_VERSION}.${VUER_BUILD_NUMBER}-${SECURITY_NUMBER}. Common infra → harbor.techteamer.com/vuer-common/<svc>:${VERSION}.${BUILD}-${COMMON_SECURITY_NUMBER}.

build.sh does NOT push to the registry

Verified: grep -n push build.sh → no docker push / no docker login. build.sh only builds and tags images locally (and exports them as .tar into the ZIP). Publishing in this legacy flow is a separate manual step / out of scope of the script. (Contrast: vuer-release CI publishes via release-tool publish push.)

  • Image signing: sign-partner.sh (v 0.1.1) wraps cosign: cosign sign --key cosign.key --annotations 'Signer=Facekom Kft' --annotations 'Signer_URL=https://facekom.net' <image_tag> (sign-partner.sh:96-97). -i single image or -t all from a tag list.
  • build-openshift.sh: an OpenShift-targeted variant whose base_build/common_build calls are commented out — runs only init+custom_build+build_pack as written (per vuer_build §10; WIP).

3.3 vuer_docker — dev/CI image builds

Built à la carte via docker-compose -f <file> up -d --build (or bin/vuer.sh docker up). Tagged harbor.techteamer.com/${PROJECT_NAME}/<svc>:<version> with PROJECT_NAME=facekom-devel (.env:1). The CI image is harbor.techteamer.com/travisci-facekom/testenv (testenv.yml). Images are pulled from Harbor in the normal dev flow; built locally only when iterating on an image. (README.md devel.)

4. Build environment & prerequisites

Concernvuer-releasevuer_buildvuer_docker
Driverexternal release-tool + GitHub Actionsbash build.shdocker-compose + bin/vuer.sh
Runnerself-hosted [self-hosted, docker]dev workstationdev workstation
Host reqsBuildKit-enabled Docker; jqUbuntu 22.04+, Docker 26.1.1+, compose 2.27.0+, git 2.34.1+ (README.md:7-12)Docker + compose; /etc/hosts wildcard DNS
Source authsecrets.RELEASE_PAT (private repo clone)host ssh-agent forwarded (SSH_AUTH_SOCK) + per-svc base/<svc>/github.key baked as /root/.ssh/id_rsahost SSH + Harbor/Oracle registry login
Registry credssecrets.HARBOR_USER/HARBOR_SECRETnot in build.sh (publish out-of-band)docker login harbor.techteamer.com
BuildKit contextsrequired — named contexts from=install-scripts,sourcecode,projects,base,buildfiles,release-tool injected by release-tool (plain docker build fails)--mount=type=bind for install/tsa steps--mount=type=bind,source=/install
Package manager (this repo)none (data + Dockerfiles)Node/Yarn only inside packaging/none (compose YAML)

vuer-release cannot be built standalone

You need (a) the private release-tool binary, (b) a RELEASE_PAT with TechTeamer private-repo access, (c) Harbor creds, (d) a BuildKit daemon (named build contexts are non-standard docker build). A plain docker build base/components/vuer_oss will fail. (Per vuer-release §10.)

vuer_build builds fail without github.key

Base Dockerfiles copy base/<svc>/github.key → /root/.ssh/id_rsa to clone private repos. *.key is gitignored (not committed); operators must drop their own key (README.md:22-28). (Per vuer_build §6.)

5. Release-repo layout (vuer-release)

Verified git ls-tree. The release-management structure:

PathRole
base/components/<comp>/base image build contexts (Dockerfile + component_env_values.json + configs); 11 comps (10 with Dockerfile, vuer_cv definition-only)
base/release/<N>/release.jsonbase release descriptors — versions 1–6 (6 releases)
base/default_env_values.jsonglobal base build-arg defaults (vuer-common)
projects/<partner>/components/<comp>/per-partner Dockerfile overrides (thin, FROM $BASE_COMPONENT_IMAGE_TAG)
projects/<partner>/release/<N>/release.jsonper-partner release descriptors
projects/default_env_values.jsonglobal project defaults
install/*.sh (+ yum/, dnf/, emrtd/, pdf/, tsa/, nginx/, supervisor/, tools/)OS/runtime install scripts bind-mounted into image builds (catalogued in vuer-release §5)
bundle-image/optional self-contained “build-in-a-container” image (gated by BUNDLE_IMAGE, currently false everywhere)
build/empty placeholder (.gitkeep); runtime temp build dir, gitignored
.github/workflows/autobuild.ymlthe only CI workflow

Release descriptor (release.json) is the central config object. Two schema variants coexist (release-tool must understand both):

  • UPPERCASE (most projects — nusz, kh, polgaribank-facekom, raiffeisen, demo-project): PROJECT_NAME, GIT_REMOTE_ORG, DOCKER_REGISTRY, RELEASE_VERSION, TIMESTAMP, BUNDLE_IMAGE, DEFAULT_ARGS{}, COMPONENT_LIST[] (each NAME/VERSION/BUILD_NUMBER/TAG + optional JANUS_REPOSITORY/JANUS_VERSION_COMMIT).
  • lowercase (legacy — equilor): project, git_remote, docker_registry, default_args, project_args, services[].

Release counts per project (verified — number of release.json files):

Projectrelease.json countLatest
base6base/6
nusz11release/12 (highest dir)
polgaribank-facekom6release/6
raiffeisen5—
kh4—
demo-project3—
equilor1release/1 (lowercase schema)
cofidis, fundamenta, generali-atvilagitas, magnet, microsec, unicredit, unicredit-srb0components only, never tagged/built

nusz: 11 files but highest dir is 12

git ls-tree counts 11 release.json under projects/nusz while the highest release dir is 12 — one version dir is absent. (The older note’s “nusz (12)” refers to the highest version number, not the file count.)

6. The active FKITDEV branches (verified via git)

None of the three repos is on its base branch at survey time

Every working tree is on a feature branch. The base branches (master/main/master) differ materially.

vuer_build → feature/FKITDEV-8868 (HEAD 341a553, 2026-05-28)

  • Commit: “fix(FKITDEV-8868): add janus admin api config to Ubi8 branch”.
  • This is the UBI8 line. diff --name-status main feature/FKITDEV-8868 touches base Dockerfiles + yum repos: deletes Oracle-Linux-9.repo + RPM-GPG-KEY-ol-9 from base contexts, renames CentOS-CRB.repo→CentOS-PowerTools.repo (CentOS Stream 8 naming), renames the bare install-nodejs.sh files (and one packaging/.../install-nodejs-22.sh) → install-nodejs-20.sh under the base contexts, adds RPM-GPG-KEY-oracleofficial + moves oracle-instantclient.repo up to base/vuer_oss/yum/. I.e. FKITDEV-8868 = “keep/return FaceKom on a UBI8-based image” with reworked CentOS-8/Oracle repos.
  • Node version (corrected): the rename added an install-nodejs-20.sh variant, but it did not switch the deployed runtime to Node 20. On this branch each of base/{vuer_oss,vuer_css,portal_css}/tools/ carries both install-nodejs-20.sh and install-nodejs-22.sh, and the three core base Dockerfiles still COPY tools/install-nodejs-22.sh + RUN sh /tmp/install-nodejs-22.sh (verified git grep -n install-nodejs HEAD -- '*Dockerfile*'; -20.sh installs NODE_VERSION=20.x, -22.sh installs 22.x). So the deployed app images = Node 22. The only consumer of install-nodejs-20.sh is the dap demo partner (partner/dap/dap_demo_partner/Dockerfile); the packaging/Dockerfile separately pins Node 20 via the NodeSource pub_20.x/el/8 RPM.
  • Local branches present: feature/FKITDEV-8252-ubi10 (2026-05-22, UBI10 variant), feature/FKITDEV-8598 (2026-05-06), feature/FKITDEV-8868, main (2026-03-27, UBI9).

vuer-release → feature/FKITDEV-8252-ubi10 (HEAD 9a54612, 2026-05-22)

  • Commit: “fix(FKITDEV-8252): make valkey config robust against valkey.conf format”.
  • The UBI9 → UBI10 migration branch. diff --name-status master HEAD = 24 files: all 9 modified base Dockerfiles + bundle-image/Dockerfile + 8 install/*.sh + 6 install/yum/*.repo. Verified changes:
    • Base OS ubi9/ubi-minimal → ubi10/ubi-minimal (e.g. base/components/vuer_oss/Dockerfile). pdfservice builder ubi9/openjdk-17 → ubi10/openjdk-21, runtime ubi9→ubi10.
    • redis → valkey (install/install-redis.sh): microdnf -y install valkey + symlinks redis-server/redis-cli//etc/redis/… → valkey equivalents (master installs real redis and sed-patches redis.conf). App configs still say redis.
    • Java 11/17 → 21 (install/install-java-11.sh & install-java-17-jre.sh): both now microdnf -y install java-21-openjdk-headless (filenames now misleading; master = java-11 / java-17).
    • Crypto policy (install/install-os.sh): adds crypto-policies-scripts + update-crypto-policies --set LEGACY (new on this branch).
  • Local branches: feature/FKITDEV-8252-ubi10, feature/FKITDEV-8352/8354/8355/8359, master (2026-05-14).

FKITDEV-8252 is a fleet-wide UBI10 effort, split across repos

vuer-release@feature/FKITDEV-8252-ubi10 (the new pipeline) and vuer_build@feature/FKITDEV-8252-ubi10 (the legacy pipeline) both migrate to UBI10. The Oracle Instant Client blocker for that effort is documented in FKITDEV-8252-oracle-ol10-memo: Oracle has no OL10 yum repo yet, so kh/bb partner images keep .el9 Instant Client RPMs on a UBI10 base (verified install/install-oracleinstantclient.sh pulls oracle-instantclient19.29-basiclite-...el9.x86_64; memo: yum.oracle.com/repo/OracleLinux/OL10/ = 404). The memo names the affected images as living in vuer_build/ (kh, bb).

vuer_docker → devel (HEAD 640d853, 2026-01-16)

  • Commit: “node 24 (#201)“. The dev env’s working branch (README tells you git checkout devel). master (2025-11-24) is a sparser production-leaning layout. Not an FKITDEV branch. (Per vuer_docker top callout.)

7. Registry: harbor.techteamer.com

The single container registry for FaceKom (a Harbor instance at harbor.techteamer.com). Verified across all three repos:

  • Default in descriptors: base/default_env_values.json:DOCKER_REGISTRY = "harbor.techteamer.com" (vuer-release).
  • Image-path conventions:
    • Base/common: harbor.techteamer.com/vuer-common/<svc>:<version>.<build>-<COMMON_SECURITY_NUMBER> (vuer_build common; vuer-release base project name vuer-common).
    • Per-partner: harbor.techteamer.com/${PROJECT_NAME}/<svc>:<version>.<build>-<SECURITY_NUMBER> (every partner Dockerfile FROM in vuer_build/partner/* and vuer-release/projects/*).
    • Dev: harbor.techteamer.com/facekom-devel/<svc>:... and CI harbor.techteamer.com/travisci-facekom/testenv (vuer_docker).
  • Auth:
    • vuer-release CI logs in via release-tool publish login with secrets.HARBOR_USER/HARBOR_SECRET → env DOCKER_REGISTRY_USERNAME/DOCKER_REGISTRY_PASSWORD.
    • vuer_docker README requires manual docker login harbor.techteamer.com (+ a container-registry.oracle.com login for the Oracle DB image).
    • vuer_build build.sh does not authenticate (no push).

Tag anatomy (consistent across pipelines): <VERSION>.<BUILD_NUMBER>-<SECURITY_NUMBER>, where VERSION is the app version (x.y.z or x.y.z.w), BUILD_NUMBER the last segment, and SECURITY_NUMBER a date-like int (e.g. base default 20250121; vuer_docker 20220315). -bv N (vuer_build) appends _N to rebuild.

8. Common infra image versions (built by the pipelines)

These are the versions the pipelines bake for the runtime stack (the apps consume them; see architecture-overview). They diverge across the three repos/branches:

Imagevuer_build (common/settings.cfg, FKITDEV-8868)vuer-release (UBI10 branch)vuer_docker (.env, devel)
RabbitMQ3.10.10 (Erlang via base)4.1.4 / Erlang 27.3.4.2 (per vuer-release §6)4.1.4 (Erlang 27.3.4.2-1.el9)
coturn (TURN)4.6.3(component present)4.5.2
ClamAV0.103.11(UBI10 + EPEL-10)ubuntu-bionic tag
PostgreSQL16.6 (postgres:16.6-bookworm)postgres:<VERSION>-bookworm16.6
Janus(compiled from $JANUS_VERSION_COMMIT)commit-pinned (60ed394… for nusz)0.12.4 @ commit b02e09ed…
Node (app)22.x (core base images still install-nodejs-22.sh on FKITDEV-8868; packaging image = Node 20, dap demo partner = Node 20)2224.x

Versions are NOT shared across repos

vuer_build/common/settings.cfg pins RabbitMQ 3.10.10 while vuer_docker and vuer-release are on 4.1.4. The three pipelines are versioned independently — do not assume a single source of truth for infra versions.

9. Verified gotchas (cross-repo)

Three base-OS lines for vuer_build; the "UBI8 everywhere" claim is branch-specific

main=UBI9, feature/FKITDEV-8868=UBI8, feature/FKITDEV-8252-ubi10=UBI10. Always check the branch. (§2 warning.)

build.sh (vuer_build) never pushes; vuer-release CI does

Legacy flow builds+exports .tar; new flow publishes to Harbor via release-tool publish push. (§3.)

vuer-release tag + path are load-bearing for CI

CI fires only on tag *@* AND a changed release.json path. base@N → base build; anything else → project. Malformed tag → parse_tag fails / builds nothing. (§3.1.)

install-java-*.sh / install-redis.sh names lie on the UBI10 branch

On vuer-release@feature/FKITDEV-8252-ubi10, both java installers install java-21, and install-redis.sh installs valkey (redis paths are symlinks). (§6.)

unicredit-srb (vuer-release) mixes override styles

Its janus/portal_css/rabbitmq/turn Dockerfiles FROM harbor.techteamer.com/... (full ref) while vuer_oss/vuer_css use $BASE_COMPONENT_IMAGE_TAG. (§2.1.)

vuer_cv is definition-only in vuer-release

base/components/vuer_cv has only component_env_values.json (PROJECT_NAME vuer-cv), no Dockerfile — so the CV image is not built by this repo’s base build. (§2.1.)

Unverified / gaps

  • External release-tool (vuer-release-cli) — all gen/build/publish, env-value precedence, source-package fetch, compose generation. Not present locally; documented only via observable inputs + the CI calls in autobuild.yml.
  • Handoff between vuer_build and vuer-release — both target the same product/registry; no file read states how/whether one supersedes the other operationally. create-build-package.js still references vuer_build@main + vuer_docker@devel. Relationship inferred, not documented in source.
  • vuer_build publish step — build.sh doesn’t push; the actual publish mechanism for the legacy flow (manual docker push? a separate script?) was not found in the files read.
  • Per-partner Dockerfile internals — surveyed by FROM line + count; the RUN steps of the ~105 vuer_build/partner/* and 37 vuer-release/projects/* overrides were not all read individually (the per-partner customization detail lives in customization-architecture / customization-branch-catalog).
  • build-openshift.sh full diff vs build.sh — confirmed base/common builds commented out (via vuer_build); not re-diffed line-by-line here.
  • Infra image cross-checks — RabbitMQ/Erlang/Janus versions for vuer-release were taken from vuer-release §6 (component_env_values) + the nusz release.json janus commit; the vuer-release component_env_values.json files were not all re-read here.
  • vuer_docker master — only enumerated, not read; this note uses the devel working tree.

Sources

Files/refs actually read or extracted during verification (all read-only git -C <repo> show/ls-tree/diff/log/for-each-ref + Read):

vuer-release (/Users/levander/coding/facekom/vuer-release)

  • .github/workflows/autobuild.yml (full), README.md (head)
  • base/default_env_values.json, projects/default_env_values.json
  • FROM extraction of all 48 tracked Dockerfiles (git ls-tree -r HEAD | grep Dockerfile)
  • base/components/vuer_oss/Dockerfile (HEAD vs master), base/components/pdfservice/Dockerfile (HEAD vs master)
  • install/install-redis.sh, install/install-java-11.sh, install/install-os.sh (HEAD vs master diffs)
  • projects/nusz/release/12/release.json; per-project release.json counts via ls-tree
  • git diff --name-status master HEAD (24 files); git for-each-ref refs/heads; git log -1

vuer_build (/Users/levander/coding/facekom/vuer_build)

  • FROM extraction of all 119 tracked Dockerfiles
  • base/vuer_oss/Dockerfile FROM across main / feature/FKITDEV-8868 / feature/FKITDEV-8252-ubi10
  • build.sh (header, tag-derivation, base_build/common_build/custom_build/build_pack, grep push), docker-compose-base.yml, common/settings.cfg, packaging/Dockerfile (FROM), sign-partner.sh (cosign), README.md (head)
  • git diff --name-status main feature/FKITDEV-8868; git for-each-ref; git log -1

vuer_docker (/Users/levander/coding/facekom/vuer_docker)

  • FROM extraction of all 18 tracked Dockerfiles (devel)
  • .env (devel); harbor image refs via git grep
  • git for-each-ref; git log -1

Other

  • /Users/levander/coding/facekom/FKITDEV-8252-oracle-ol10-memo.md
  • Orientation (independently re-verified): /Users/levander/levandor_obsidian/projects/facekom-v2/repos/{vuer_build,vuer-release,vuer_docker}.md

Graph View

Backlinks