vuer-release

Release-management and Docker-image-build orchestration repo for FaceKom v2. It holds declarative release descriptors (release.json), Dockerfiles for every component (base + per-partner overrides), and OS install scripts baked into those images. It contains no application source code and no build logic of its own — the actual build/publish engine is an external Go-ish binary, release-tool (from TechTeamer/vuer-release-cli), invoked by CI and by developers. (README.md:1-10, .github/workflows/autobuild.yml).

Branch under inspection

The working tree was checked out on feature/FKITDEV-8252-ubi10 (HEAD 9a54612), not master. That branch migrates every image from UBI9 → UBI10, swaps redis → valkey, and bumps Java 11/17 → 21. Where this doc shows UBI10/valkey/Java-21, master still uses UBI9/redis/Java-11+17. The master/HEAD divergence is exactly 26 files (all Dockerfiles + install/*.sh + install/yum/*.repo). See customization-branch-catalog. Verified: git diff --name-status master HEAD; git show master:base/components/vuer_oss/Dockerfile; git show master:install/install-redis.sh.

1. Purpose & role in FaceKom

This repo is the release source-of-truth + image factory for the FaceKom video-identification platform. Per README.md:1-3:

“This repository manages base (common) and project-specific releases and builds the corresponding Docker images.”

Flow (README.md:17-28):

A developer runs the external release CLI (release-tool) locally → it generates a release.json descriptor, commits it, and pushes a git tag of the form <name>@<version> (e.g. nusz@12, base@6).
The tag triggers GitHub Actions (.github/workflows/autobuild.yml).
The workflow runs on a self-hosted runner (runs-on: [self-hosted, docker]), downloads release-tool, then runs gen → build → publish to build Docker images and push them to the configured registry (harbor.techteamer.com).
Image list + build logs are uploaded as job artifacts.

There are two kinds of release:

base (base/release/<N>/release.json) — shared infrastructure + base application images (project vuer-common).
project (projects/<PARTNER>/release/<N>/release.json) — per-partner images that FROM the base images and apply customizations.

This repo is data + Dockerfiles, not an app

There is no package.json, build.gradle, pom.xml, requirements.txt, go.mod, etc. anywhere in the tree (verified: git ls-tree -r HEAD | grep -iE 'package.json|build.gradle|pom.xml|...' → none). The repo is consumed by the external release-tool; you cannot “build” it standalone.

2. Tech stack & runtime

Aspect	Value	Source
Repo language	Bash (install/build scripts) + JSON (descriptors) + Dockerfile	tree
Build engine	external `release-tool` binary (`TechTeamer/vuer-release-cli`)	`README.md:8-15`, `.github/workflows/autobuild.yml` (Download Release CLI step)
CI	GitHub Actions, self-hosted runner labelled `[self-hosted, docker]`	`.github/workflows/autobuild.yml`
Container base	`registry.access.redhat.com/ubi10/ubi-minimal` (this branch; UBI9 on master)	`base/components/*/Dockerfile`
Registry	`harbor.techteamer.com` (Harbor)	`base/default_env_values.json:3`
Docker BuildKit	required — Dockerfiles use named build contexts (`--mount=type=bind,from=install-scripts`, `from=sourcecode`, `from=projects`, `from=base`, `from=buildfiles`, `from=release-tool`) wired up by `release-tool`	`base/components/vuer_oss/Dockerfile:11,53`; `bundle-image/Dockerfile:31-45`
Node version (default)	22	`base/default_env_values.json:7`, `projects/default_env_values.json:4`
jq	required (parses `release.json` in shell)	`bundle-image/bundle_build_context.sh:25`

No package manager for this repo

The Node/yarn tooling (install-app.sh, install-nodejs.sh) installs into the built images, not into this repo. This repo itself has no dependencies to install.

3. Build & run

Entrypoints

There is no main/bin for this repo. The “entrypoint” is the external release-tool CLI plus the CI workflow. Sub-images have their own CMD (almost all are supervisord, see §6).

CI workflow — `.github/workflows/autobuild.yml`

Triggered on push of tags matching *@*, restricted to paths projects/*/release/*/release.json and base/release/*/release.json. Jobs:

parse_tag — splits the git tag on the first @ into project_name + release_version. base@N → base release; anything else → project release.
build:
- actions/checkout@v4.
- Set Token — writes a RELEASE_PAT-based ~/.git-credentials (needed to clone the private component source repos).
- Download Release CLI — pulls the release_tool asset from the latest GitHub release of TechTeamer/vuer-release-cli via the GitHub API (auth secrets.RELEASE_PAT), chmod +x, adds to $PATH as release-tool.
- Configure Release CLI — release-tool --offline config set release_repo_path <workspace>.
- Build project release (if not base@): release-tool --offline gen project -p <name> -r <ver> then ... build project ....
- Build base release (if base@): release-tool --offline gen base -r <ver> then ... build base ....
- Publish (project or base): release-tool --offline publish login ... then ... publish push ... using secrets.HARBOR_USER / secrets.HARBOR_SECRET env DOCKER_REGISTRY_USERNAME / DOCKER_REGISTRY_PASSWORD.
- Built Image List — runs docker images against build/image/<list> to produce build/image/image_list.log.
- Upload artifact — uploads build/image/image_list.log and build/log/*.log as <project>-<version>-release-artifact.

Local release (developer)

README.md:12-21: download the release_tool binary, run it to generate release.json, it commits + pushes the tag. Exact CLI flags live in the external vuer-release-cli repo (not here).

Dockerfiles present

One per base component: base/components/<comp>/Dockerfile (11 components, see §6).
One per project override where a partner customizes a component: projects/<partner>/components/<comp>/Dockerfile.
One bundle image: bundle-image/Dockerfile (see §6 “bundle-image”).
Verified: git ls-tree -r HEAD | grep Dockerfile.

Scripts

This repo has no package.json scripts (none exists). The shell helper scripts are catalogued exhaustively in §5.

4. Top-level structure

Verified via git ls-tree. 362 tracked files total.

Path	Role	Source
`README.md`	Repo + release-descriptor documentation	read
`.github/workflows/autobuild.yml`	The only CI workflow — build & publish on tag	read
`base/components/<comp>/`	Base Docker images: Dockerfile + `component_env_values.json` (+ configs) for 11 components	listed
`base/release/<N>/release.json`	Base release descriptors (versions 1–6)	listed
`base/default_env_values.json`	Global default build args for base (`vuer-common`)	read
`projects/<partner>/`	Per-partner projects: `components/` overrides, `release/<N>/release.json`, `project_env_values.json`	listed
`projects/default_env_values.json`	Global default build args for projects	read
`install/*.sh`	OS/runtime install scripts bind-mounted into image builds	read (all, §5)
`install/yum/`, `install/dnf/`	Repo definitions + GPG keys + `dnf.conf` for the image package installs	listed/read
`install/emrtd/`	eMRTD (passport/ID chip) reader: `vuer_emrtd` launcher + JMRTD/DSS jars + Hungarian CSCA certs	listed
`install/pdf/`	`facekom_pdf_signer` launcher + PDFBox/BouncyCastle jars + fonts	listed
`install/tsa/live/`	e-Szignó TSA / CA trust certs (for timestamping)	listed
`install/nginx/`	nginx snippets: `gzip.conf`, `proxy.conf`, `security.conf`, `ssl.conf`	listed/read
`install/supervisor/`	base `supervisord.conf` + empty `conf.d/`	read
`install/tools/`	`install-nodejs-22.sh`, `supervisor-health-check.sh`	read
`bundle-image/`	Self-contained “build-in-a-container” image (Dockerfile + `bundle_build_context.sh` + `config.json`)	read
`build/`	Empty placeholder (`build/.gitkeep`); gitignored at runtime — temp build dir used by `release-tool`	`README.md:36`
`.editorconfig`, `.gitignore`	2-space LF; ignores `.idea`, `.log`, `.key`, `.pub`	read
`.agents/`	Local agent tooling (`ao/`) — not tracked in git	`git ls-tree` (absent)

5. Helper scripts (all first-party `install/` scripts — read in full)

These run inside image builds, bind-mounted at /install via BuildKit --mount=type=bind,from=install-scripts. They run as root in the build stage; most take $DOCKER_USER (default techteamer) as $1 and chown runtime dirs to it.

Script	What it does
`install/install-os.sh`	Base OS prep: copies `dnf.conf`, `microdnf update`, installs `crypto-policies-scripts shadow-utils procps tar cpio findutils openssl which gzip`, then `update-crypto-policies --set LEGACY`.
`install/install-utils.sh`	`microdnf install nano net-tools procps tar`.
`install/install-app.sh`	Installs the Node app: copies `yarn.repo`, installs `yarn gcc-c++ make git`, then as `$USER` runs `yarn install --production; npm run build --if-present; yarn cache clean`, then removes yarn/git build deps. Args: `$1=APP_HOME`, `$2=USER` (default root).
`install/configure-app.sh`	Symlinks any `$APP_HOME/nginx.conf` → `/etc/nginx/conf.d/` and `$APP_HOME/supervisor.conf` → `/etc/supervisor/conf.d/`, chowns supervisor conf.d. Args: `$1=APP_HOME`, `$2=DOCKER_USER`.
`install/install-nodejs.sh`	Writes a NodeSource yum repo for `pub_${NODE_VERSION}.x` and `microdnf makecache`. Requires `$1=NODE_VERSION` (exits if empty). Note: only sets up the repo + cache; actual `nodejs` install happens elsewhere (the repo is consumed by `install-app.sh`’s yarn/build).
`install/tools/install-nodejs-22.sh`	Same as above but hardcoded `NODE_VERSION=22.x` and `pub_22.x` path.
`install/install-nginx.sh`	Installs nginx, copies `install/nginx/*` to `conf.d`, removes `default.conf`, moves pid to `/tmp/nginx.pid`, comments `user nginx;`, generates `dhparam.pem` (2048), chowns nginx dirs. Arg `$1=DOCKER_USER`.
`install/install-redis.sh`	Installs `valkey` (not redis on this branch), symlinks `redis-server`/`redis-cli`/`/etc/redis`/etc. → valkey equivalents, appends config to `valkey.conf` (`daemonize no`, `port 0`, unix socket `/var/run/redis/redis-server.sock`, `appendonly no`, `save ""`, `maxmemory $2` default `512mb`, `maxmemory-policy allkeys-lru`). Args `$1=DOCKER_USER`, `$2=MAX_MEMORY`.
`install/install-rabbitmq.sh`	Copies RabbitMQ signing keys + erlang/rabbitmq repos, installs `erlang-${2}` and `rabbitmq-server-${1}`. Args `$1=RABBITMQ_VERSION`, `$2=ERLANG_VERSION`.
`install/install-supervisor.sh`	`pip3 install supervisor==4.3.0`, copies `install/supervisor` → `/etc/supervisor`, sets perms/ownership, installs `tools/supervisor-health-check.sh` → `/usr/local/bin/`. Arg `$1=DOCKER_USER`.
`install/tools/supervisor-health-check.sh`	HEALTHCHECK script: exit 1 if any `supervisorctl status` line is not `RUNNING`, or if any program’s uptime matches `[0-9]*:00:[0-5][0-9]` (i.e. crash-looping within the first hour).
`install/install-java-11.sh`	Installs `java-21-openjdk-headless` (this branch) + `tzdata-java`; patches `java.security` to use `/dev/urandom` and `NativePRNGNonBlocking`. (On master: java-11.)
`install/install-java-17-jre.sh`	Identical to `install-java-11.sh` on this branch — also installs `java-21-openjdk-headless`. (On master: java-17.)
`install/install-coturn.sh`	Installs EPEL-10 release rpm + `coturn`, chowns `/var/log/coturn /var/lib/coturn /etc/coturn`. Args `$1=DOCKER_USER`, `$2=TURN_VERSION_NUMBER`, `$3=TURN_EPEL_VERSION_NUMBER`.
`install/install-janus-build-env.sh`	Heaviest script. Sets LEGACY crypto policy, adds CentOS + EPEL-10 + RPMFusion repos, removes `openssl-fips-provider-so`, installs a big toolchain (ffmpeg-devel, libogg, jansson, openssl-devel, glib2, cmake, automake, libtool, gnutls, libcurl, libconfig, etc.), then downloads & compiles from source: libnice 0.1.17, libsrtp 2.5.0 (`--enable-openssl`), libwebsockets 4.3.3 (LWS_MAX_SMP=1, server/test/client disabled), and unpacks janus-gateway from `$JANUS_REPOSITORY` @ `$JANUS_VERSION_COMMIT` then runs `autogen.sh`. Args `$1=JANUS_REPOSITORY`, `$2=JANUS_VERSION_COMMIT`.
`install/install-janus-runtime-env.sh`	Janus runtime deps: LEGACY crypto, removes `openssl-fips-provider-so`, installs `libconfig jansson`; if `$1` non-empty, adds EPEL-10 + RPMFusion and `microdnf install $@` (e.g. `ffmpeg` for post-processing).
`install/install-emrtd.sh`	Copies `install/emrtd/*` → `/opt/facekom/emrtd`, chowns, `chmod 755` the `vuer_emrtd` launcher. Arg `$1=DOCKER_USER`.
`install/install-pdfsigner.sh`	Copies `install/pdf/*` → `/opt/facekom/pdf`, chowns `/opt/facekom`. Arg `$1=DOCKER_USER`.
`install/install-tsa.sh`	Copies `install/tsa/live/` into OpenSSL `certs` dir and creates the hashed `.0` symlinks for the e-Szignó TSA/CA trust chain; `chmod +r`.
`install/install-oracleinstantclient.sh`	Copies Oracle GPG key + repo, installs `oracle-instantclient19.29-basiclite-19.29.0.0.0-1.el9.x86_64`.
`install/install-python.sh`	Installs `python3 python3-pip`, symlinks `python`, upgrades pip, installs `setuptools==75.1.0`.

6. Key components / images

Each base component is a multi-stage Dockerfile under base/components/<comp>/ plus a component_env_values.json of default build args. 11 components (verified git ls-tree base/components):

Component	What the image is	Base / key build steps	CMD
vuer_oss	The main FaceKom application (the OSS video-identification node app).	2-stage: compiles Janus from source (post-processing, plugins disabled), then UBI10 build stage installing supervisor + nginx + nodejs + valkey + TSA certs + Java (21) + pdfsigner + emrtd + janus runtime (ffmpeg), copies Janus binaries/libs, unpacks app tar (`from=sourcecode`), runs `install-app.sh`. `JANUS_VERSION_COMMIT` default `cc0fdca…`.	`supervisord`
vuer_css	The CSS / signalling companion node app (control server).	UBI10: supervisor + nodejs + nginx + valkey, unpack app, `install-app.sh`.	`supervisord`
vuer_cv	Computer-vision service. Definition-only on this branch — has `component_env_values.json` (`PROJECT_NAME: vuer-cv`) but no Dockerfile in this repo (verified: `git ls-tree base/components/vuer_cv` → only the json).	—	—
janus	Standalone Janus WebRTC gateway image (echotest + videoroom plugins, websockets transport enabled).	2-stage compile + runtime; copies libsrtp/libnice/libwebsockets + janus binaries; `COPY supervisor/` (janus.conf). VERSION 1.4.1.	`supervisord` (runs `janus`)
turn	coturn TURN/STUN server.	UBI10 + supervisor + coturn; `COPY supervisor/` (turnserver.conf → `turnserver -c /etc/turnserver.conf`).	`supervisord`
rabbitmq	RabbitMQ broker (the FaceKom message bus).	UBI10 + supervisor + `install-rabbitmq.sh`; RabbitMQ 4.1.4 / Erlang 27.3.4.2; technical user `techteamer`; `rabbitmq.sh` wrapper traps TERM.	`supervisord` → `rabbitmq.sh`
postgresql	PostgreSQL DB, rootless-patched.	`FROM postgres:${VERSION}-bookworm` (Debian, not UBI); remaps postgres uid/gid to `$UID/$GID`, custom `docker-entrypoint.sh` (the standard docker-library postgres entrypoint, 347 lines).	`postgres`
clamav	ClamAV antivirus (file scanning).	UBI10 + EPEL-10 `clamd clamav-update` + supervisor.	`supervisord`
pdfservice	PDF signing/validation service (Gradle/Java).	2-stage: `ubi10/openjdk-21` builder runs `./gradlew distTar`, copies TSL `tl_cache`; runtime `ubi10/ubi-minimal` + Java-17-JRE (→21) + TSA certs + fontconfig/freetype. Env `FACEKOM_PDF_SIGNER_TSA_USERNAME/PASS`. Expects volumed `local.properties`.	`supervisord`
resource-manager	Node resource-manager service.	UBI10 + supervisor + nodejs, unpack app, `install-app.sh`.	`supervisord`
nyilvantarto_scraper	Hungarian registry (“nyilvántartó”) scraper, Node.	UBI10 + supervisor + nodejs; unpacks `nyilvantarto_scraper` → `/workspace/nyilvantarto`.	`supervisord`

vuer_oss process model

From a partner override (projects/polgaribank-facekom/components/vuer_oss/supervisor_vuer_oss_docker.conf), the running vuer_oss container runs under supervisor: nginx, redis (valkey via symlink, redis-server /etc/redis/redis.conf), and node processes server.js, media.js (vuer_media), convert.js, cron.js (vuer_cron), background.js. This is the canonical FaceKom app process set. See vuer_oss.

Project override mechanism

A partner that customizes a component drops a thin Dockerfile in projects/<partner>/components/<comp>/Dockerfile:

ARG BASE_COMPONENT_IMAGE_TAG
FROM $BASE_COMPONENT_IMAGE_TAG
COPY temp_path.conf /etc/nginx/conf.d/        # e.g. read-only-fs nginx temp paths
COPY supervisor_vuer_oss_docker.conf /etc/supervisor/conf.d/
USER techteamer
CMD ["/usr/local/bin/supervisord", "-n", "-c", "/etc/supervisor/supervisord.conf"]

$BASE_COMPONENT_IMAGE_TAG is supplied by release-tool, pointing at the just-built base image. Per-component overrides can also set component_env_values.json (e.g. polgaribank pins its own JANUS_VERSION_COMMIT). Verified: projects/polgaribank-facekom/components/vuer_oss/{Dockerfile,component_env_values.json,supervisor_vuer_oss_docker.conf}. See customization-architecture.

bundle-image (`bundle-image/`)

An optional self-contained build container (gated by BUNDLE_IMAGE in release.json). bundle-image/Dockerfile: FROM ubi10/ubi-minimal, installs docker-ce + jq + python3, copies bundle_build_context.sh and config.json (which sets release_repo_path=/workspace), and during build runs bundle_build_context.sh <PROJECT> <VERSION> to assemble a /workspace containing the release.json, base Dockerfiles, base compose files (/mnt/build/<svc>.base.docker-compose.yml), the install/ tree, and the release-tool binary; ENTRYPOINT ["./build/entrypoint.sh"]. It bind-mounts six named contexts: install-scripts, projects, buildfiles, release-tool, base. (bundle-image/Dockerfile:31-49, bundle-image/bundle_build_context.sh).

BUNDLE_IMAGE is currently false everywhere

Every release.json that has the field sets "BUNDLE_IMAGE": false (verified across raiffeisen/nusz/demo-project releases). The bundle image path is plumbed but not enabled in current descriptors.

7. Configuration

Release descriptors — `release.json`

The central config object. Fields (README.md:63-85):

PROJECT_NAME, GIT_REMOTE_ORG, DOCKER_REGISTRY, RELEASE_VERSION, TIMESTAMP, DEFAULT_ARGS (default Docker build args), COMPONENT_LIST (each with NAME, TAG, VERSION, BUILD_NUMBER).
Per-component extras seen in practice: JANUS_REPOSITORY, JANUS_VERSION_COMMIT, JAVA_VERSION, per-component UID/GID.
Optional top-level: BUNDLE_IMAGE (bool), RELEASE_COMMENT.

TWO release.json schema variants exist

Most projects (nusz, kh, polgaribank-facekom, raiffeisen, demo-project) use the UPPERCASE schema (PROJECT_NAME, DEFAULT_ARGS, COMPONENT_LIST). equilor uses an older lowercase schema: project, git_remote, docker_registry, default_args, project_args, services[] (with name/version/tag/build_number). The README documents only the uppercase form. release-tool must understand both. Verified: projects/equilor/release/1/release.json vs projects/nusz/release/12/release.json.

Default env values (build-arg defaults)

base/default_env_values.json: PROJECT_NAME=vuer-common, DOCKER_REGISTRY=harbor.techteamer.com, GIT_REMOTE_ORG=https://github.com/TechTeamer, SECURITY_NUMBER=20250121, UID=1000, GID=1000, NODE_VERSION=22, RUNTIME_ENV=docker.
projects/default_env_values.json: GIT_REMOTE_ORG, DOCKER_REGISTRY, NODE_VERSION=22.
Per project: projects/<partner>/project_env_values.json (e.g. demo-project: PROJECT_NAME, GID/UID=2000, SECURITY_NUMBER).
Per component: base/components/<comp>/component_env_values.json and projects/<partner>/components/<comp>/component_env_values.json.

Precedence

The layering (*default_env_values.json → project_env_values.json → component_env_values.json → release.json DEFAULT_ARGS/COMPONENT_LIST) is resolved by the external release-tool — the merge logic is not in this repo. Treated here as observed inputs only.

CI secrets (`.github/workflows/autobuild.yml`)

secrets.RELEASE_PAT — GitHub PAT to download the CLI + clone private source repos.
secrets.HARBOR_USER / secrets.HARBOR_SECRET → DOCKER_REGISTRY_USERNAME / DOCKER_REGISTRY_PASSWORD for the registry push.

Image-level config files (baked in)

nginx: install/nginx/{gzip,proxy,security,ssl}.conf (e.g. security.conf = server_tokens off;).
supervisor: install/supervisor/supervisord.conf (includes /etc/supervisor/conf.d/*.conf, socket /tmp/supervisor.sock).
dnf: install/dnf/dnf.conf (install_weak_deps=False, tsflags=...NODOCS, gpgcheck=True).
rabbitmq: rabbitmq.config, rabbitmq-env.conf (SERVER_ADDITIONAL_ERL_ARGS="+S 1:1"), supervisor program def.

No AJV / getconfig schema

Searched: there is no JSON-schema / AJV / getconfig validation in this repo. release.json structure is enforced (if at all) by the external release-tool, not here.

8. Tests

No tests in this repo

There is no test framework, no test directory, and no test files (verified: git ls-tree -r HEAD | grep -iE 'test|spec|jest|mocha|pytest' matches only vendored jars under install/emrtd/lib and install/pdf/lib — kotlin-test-*.jar, specs-*.jar). Validation of a release is done by actually running release-tool gen/build in CI on tag push.

9. Dependencies on other FaceKom services

Evidenced structurally (this repo defines the images, not the inter-service wiring; runtime topology lives in each app’s own config). What is verifiable here:

RabbitMQ — first-class component (base/components/rabbitmq, RabbitMQ 4.1.4 / Erlang 27.3.4.2). The FaceKom message bus image is built here; queue names/bindings are not defined in this repo.
PostgreSQL — DB image built here (base/components/postgresql, postgres:<VERSION>-bookworm, rootless).
Redis/Valkey — every app image (vuer_oss, vuer_css) installs valkey locally via install-redis.sh and exposes it on unix socket /var/run/redis/redis-server.sock (appendonly no, save "", allkeys-lru) — i.e. an in-container cache, not a shared service.
Janus / coturn — WebRTC media (janus, turn components) — the media plane for the video-id sessions.
Source component repos — at build time release-tool clones each component’s source from GIT_REMOTE_ORG (https://github.com/TechTeamer / git@github.com:TechTeamer) at the descriptor’s VERSION/GIT_REF, packaged as $SOURCE_PACKAGE.tar.gz and bind-mounted as the sourcecode context (base/components/*/Dockerfile). The Janus source comes from TechTeamer/janus-gateway at a pinned JANUS_VERSION_COMMIT.

Out of scope here

Actual RabbitMQ queue names, HTTP endpoints, and DB schemas are not in this repo — they live in the application repos (e.g. vuer_oss). Do not infer the runtime mesh from this repo alone.

10. Verified gotchas

install-java-11.sh and install-java-17-jre.sh both install Java 21 on this branch

Despite the filenames (and the JAVA_VERSION: "17" in base/release/6/release.json), on feature/FKITDEV-8252-ubi10 both scripts microdnf install java-21-openjdk-headless. The script names are now misleading. (master installs java-11 / java-17 respectively.)

install-redis.sh installs valkey, not redis

All redis-server/redis-cli//etc/redis paths are symlinks to valkey. App configs still say redis. (master installs real redis.) Per FKITDEV-8252 memo.

install-oracleinstantclient.sh pulls an .el9 RPM on a UBI10 image

oracle-instantclient19.29-basiclite-...el9.x86_64 is explicitly an EL9 package even though the base is UBI10. Potential ABI mismatch — flagged, not validated here.

Builds require external infra to even run

You cannot build this repo without: (a) the private release-tool binary, (b) a RELEASE_PAT with access to TechTeamer private repos, (c) Harbor credentials, (d) a BuildKit-enabled Docker daemon (the named build contexts from=install-scripts etc. are non-standard docker build and are injected by release-tool). A plain docker build base/components/vuer_oss will fail.

Tag format is load-bearing

CI only fires on tags matching *@* AND a changed release.json path. base@N routes to the base build; everything else is treated as a project name. A malformed tag (no @, or wrong path) silently builds nothing or fails parse_tag.

Several projects have components but no published release yet

Projects with 0 release.json files: cofidis, fundamenta, generali-atvilagitas, magnet, microsec, unicredit, unicredit-srb. They define components//project_env_values.json only — nothing has been tagged/built. Projects with releases: nusz (12), polgaribank-facekom (6), raiffeisen (5), kh (4), demo-project (3), equilor (1); base has 6. (Counts verified per project.)

Unverified / gaps

External release-tool logic — all gen/build/publish behaviour, env-value precedence/merging, source-package fetching, and compose generation live in TechTeamer/vuer-release-cli (a separate repo, not present locally). Documented here only via its observable inputs (release.json, Dockerfiles, CI invocations) and the CLI calls in autobuild.yml. Not read.
base/components/postgresql/docker-entrypoint.sh (347 lines) — confirmed to be the upstream docker-library postgres entrypoint (vendored); read head + structure only, not line-by-line.
Vendored jars/certs — install/emrtd/lib/*.jar (~90 jars: JMRTD, DSS 6.0, BouncyCastle, etc.), install/pdf/lib/*.jar (PDFBox/BouncyCastle), and all install/emrtd/certs, install/tsa/live certs — surveyed by filename only, not inspected. These are third-party redistributables.
install/yum/* repo defs and GPG keys — listed; the modified CentOS-*.repo / cuda-rhel9.repo (in the master↔HEAD diff) were not diffed line-by-line.
Per-partner release.json history — I read representative descriptors (base/6, demo-project/3, polgaribank/6, nusz/12, equilor/1) and the latest of each project; I did not read every one of the ~30+ historical release files individually.
rabbitmq.config (Erlang term config) — file present, not read in full (read rabbitmq-env.conf, rabbitmq.sh, and the supervisor program def).
clamav.conf / janus full configs — the *.conf runtime configs beyond what is quoted were not all read line-by-line.

Sources

Files/dirs actually read or listed:

README.md, .gitignore, .editorconfig
.github/workflows/autobuild.yml
bundle-image/Dockerfile, bundle-image/bundle_build_context.sh, bundle-image/config.json
base/default_env_values.json, projects/default_env_values.json
base/release/6/release.json
base/components/vuer_oss/Dockerfile, base/components/vuer_oss/component_env_values.json
base/components/janus/Dockerfile, base/components/janus/component_env_values.json, base/components/janus/supervisor/janus.conf
base/components/rabbitmq/Dockerfile, …/component_env_values.json, …/rabbitmq.sh, …/rabbitmq-env.conf, …/supervisor/conf.d/supervisor_rabbitmq.conf
base/components/postgresql/Dockerfile, …/docker-entrypoint.sh (head)
base/components/resource-manager/Dockerfile, base/components/turn/Dockerfile, …/turn/supervisor/turnserver.conf
base/components/clamav/Dockerfile, base/components/pdfservice/Dockerfile, base/components/nyilvantarto_scraper/Dockerfile, base/components/vuer_css/Dockerfile
base/components/vuer_cv/component_env_values.json
install/ — all 19 *.sh scripts read in full (configure-app, install-app, install-coturn, install-emrtd, install-janus-build-env, install-janus-runtime-env, install-java-11, install-java-17-jre, install-nginx, install-nodejs, install-oracleinstantclient, install-os, install-pdfsigner, install-python, install-rabbitmq, install-redis, install-supervisor, install-tsa, install-utils) + install/tools/install-nodejs-22.sh, install/tools/supervisor-health-check.sh
install/supervisor/supervisord.conf, install/dnf/dnf.conf, install/nginx/security.conf
projects/demo-project/ (tree, project_env_values.json, release/3/release.json, components/vuer_oss/Dockerfile, components/postgresql/Dockerfile, components/resource-manager/component_env_values.json)
projects/polgaribank-facekom/ (tree, release/6/release.json, components/vuer_oss/{Dockerfile,component_env_values.json,supervisor_vuer_oss_docker.conf})
projects/equilor/release/1/release.json, projects/nusz/release/12/release.json
git (read-only): for-each-ref, log, diff --name-status master HEAD, show master:<file> (vuer_oss Dockerfile, bundle Dockerfile, install-java-11.sh, install-redis.sh), ls-tree

Levandor

Explorer

vuer-release — Release & Docker Image Build Orchestration

vuer-release

1. Purpose & role in FaceKom

2. Tech stack & runtime

3. Build & run

Entrypoints

CI workflow — `.github/workflows/autobuild.yml`

Local release (developer)

Dockerfiles present

Scripts

4. Top-level structure

5. Helper scripts (all first-party `install/` scripts — read in full)

6. Key components / images

Project override mechanism

bundle-image (`bundle-image/`)

7. Configuration

Release descriptors — `release.json`

Default env values (build-arg defaults)

CI secrets (`.github/workflows/autobuild.yml`)

Image-level config files (baked in)

8. Tests

9. Dependencies on other FaceKom services

10. Verified gotchas

Unverified / gaps

Sources

Graph View

Table of Contents

Backlinks

Levandor

Explorer

vuer-release — Release & Docker Image Build Orchestration

vuer-release

1. Purpose & role in FaceKom

2. Tech stack & runtime

3. Build & run

Entrypoints

CI workflow — .github/workflows/autobuild.yml

Local release (developer)

Dockerfiles present

Scripts

4. Top-level structure

5. Helper scripts (all first-party install/ scripts — read in full)

6. Key components / images

Project override mechanism

bundle-image (bundle-image/)

7. Configuration

Release descriptors — release.json

Default env values (build-arg defaults)

CI secrets (.github/workflows/autobuild.yml)

Image-level config files (baked in)

8. Tests

9. Dependencies on other FaceKom services

10. Verified gotchas

Unverified / gaps

Sources

Graph View

Table of Contents

Backlinks

CI workflow — `.github/workflows/autobuild.yml`

5. Helper scripts (all first-party `install/` scripts — read in full)

bundle-image (`bundle-image/`)

Release descriptors — `release.json`

CI secrets (`.github/workflows/autobuild.yml`)