Levandor

FKITDEV-8344 — vuer_build → vuer-release partner-migration batch (7 tickets)

9 min read

FKITDEV-8344 — vuer_build → vuer-release partner-migration batch

Migrating legacy vuer_build/partner/<name>/ partner build configs to the new Gen2 “lean” vuer-release/projects/<name>/ format. This note captures the reusable recipe (the durable knowledge) plus the outcome of the 7-ticket batch done this session. The companion review note FKITDEV-8354-mvm-supervisor-config-dedup is the worked precedent for the supervisor-config drop decision; this note generalizes it into a repeatable procedure.

For Agents

  • Parent ticket: FKITDEV-8344 “vuer-release migráció” (Task, In-progress). Migration steps live in FKITDEV-8344 (the raw ticket dossier).
  • Repo / branch: TechTeamer/vuer-release, branch feature/FKITDEV-8344-vuer-release-migrations off origin/master.
  • Worktree: /Users/levander/coding/facekom/vuer-release/.worktrees/vuer-migrations
  • State 2026-06-17: all 7 tickets’ file trees written in the worktree. NOTHING committed or pushed — the /fk-ticket analyze gate is armed (awaiting the user’s explicit “go”). No PRs created.
  • These supersede vencelvarga’s stale open PRs 21 (wrong janus versions, unicode-corrupted filenames, 29 MB committed Oracle tarball — see Supersedes stale PRs).
  • The single biggest insight: drop the standard supervisor_<svc>_docker.conf program configs — the app source package provides them. Only keep temp_path.conf, the supervisor-stdout logger apparatus, and customized eventlistener confs. Matches the human guidance “felesleges supervisor konfig”.

What “Gen2 lean” means

vuer-release is the modern release/build-orchestration repo (see vuer-release). Where the legacy vuer_build partner dirs carried a full Dockerfile per component (multi-ARG, hardcoded paths, bespoke install steps, and a copy of every supervisor program config), the Gen2 vuer-release/projects/<name>/ layout is thin: it carries only env-value JSON (consumed by the release tool) plus a minimal Dockerfile that FROMs the pre-built base component image and layers only genuine partner customizations on top. The app’s own files — including its supervisor program configs — arrive via the baked source package, so the partner dir does not duplicate them.

vuer-release/projects/<name>/
├── project_env_values.json                 # org + project name + security number
├── components/
│   ├── janus/component_env_values.json     # janus version pin (env-only unless CUSTOM_SERVICES)
│   ├── vuer_css/Dockerfile                  # lean: FROM base, [temp_path.conf], USER, CMD
│   ├── vuer_oss/Dockerfile
│   ├── vuer_oss/component_env_values.json   # {JANUS_REPOSITORY, JANUS_VERSION_COMMIT}
│   └── portal_css/Dockerfile               # (only if the partner builds portal)
└── release/.gitkeep                         # release/N/release.json are release-tool artifacts, NOT in the PR

The reusable RECIPE

One-line procedure

For each partner: copy the env values out of vuer_build/partner/<name>/settings.cfg into the JSON files, write a lean Dockerfile per component that FROMs $BASE_COMPONENT_IMAGE_TAG, drop the standard supervisor confs, and keep only temp_path.conf + the stdout-logger apparatus + any customized eventlistener conf.

Source and target

Legacy (source)Gen2 (target)
Rootvuer_build/partner/<name>/vuer-release/projects/<name>/
Configsettings.cfg (shell vars) + per-component dirs*_env_values.json (release-tool inputs)
Dockerfilefull, multi-ARG, bespoke installslean, FROM $BASE_COMPONENT_IMAGE_TAG

Files to produce per partner

1. project_env_values.json — top-level project identity:

{
  "GIT_REMOTE_ORG": "https://github.com/TechTeamer",
  "PROJECT_NAME": "<from settings.cfg>",
  "SECURITY_NUMBER": "<from settings.cfg>"
}
  • PROJECT_NAME keeps any -facekom suffix (e.g. polgaribank-facekom). Some partners have no suffix at all (e.g. szerencsejatek, mkb-instant) — take it verbatim from settings.cfg, do not invent or strip.
  • SECURITY_NUMBER comes straight from settings.cfg.

2. components/janus/component_env_values.json — janus is env-only (no Dockerfile) unless janus appears in the partner’s CUSTOM_SERVICES:

{
  "VERSION": "<settings.cfg>",
  "JANUS_REPOSITORY": "TechTeamer/janus-gateway",
  "JANUS_VERSION_COMMIT": "<settings.cfg>",
  "BUILD_NUMBER": "<settings.cfg>"
}

3. components/<vuer_css|vuer_oss|portal_css>/Dockerfile — the lean form:

ARG BASE_COMPONENT_IMAGE_TAG
FROM $BASE_COMPONENT_IMAGE_TAG
# COPY temp_path.conf /etc/supervisor/conf.d/temp_path.conf   # only where the partner has it
USER techteamer
CMD ["supervisord", "-c", "/etc/supervisor/supervisord.conf"]

4. components/vuer_oss/component_env_values.json — vuer_oss carries the janus link too:

{ "JANUS_REPOSITORY": "...", "JANUS_VERSION_COMMIT": "..." }

5. release/.gitkeep — keep the release/ dir tracked but empty. release/N/release.json are release-tool artifacts and are NOT part of the migration PR — do not hand-author or commit them.

The DROP rule (the key insight)

Drop the standard supervisor program configs — they are superfluous

The legacy vuer_build Dockerfiles COPY a supervisor_<svc>_docker.conf (the program definitions for nginx/redis/vuer_oss/cron/…). In Gen2 these are redundant and must be dropped. The app source package already provides them: the base image’s install/configure-app.sh symlinks every $APP_HOME/supervisor*.conf from the extracted source package into /etc/supervisor/conf.d/, and supervisord.conf includes files = /etc/supervisor/conf.d/*.conf. Carrying the partner copy duplicates what the symlink already provides. This is exactly the human guidance “felesleges supervisor konfig” (“superfluous supervisor config”).

KEEP only these supervisor-adjacent files:

KeepWhenWhy
temp_path.confpartner has itnginx readonly /run path overrides (hardened SaaS); not provided by the source package
supervisor-stdout logger apparatus (supervisor_stdout.py + supervisor_stdout_eventlistener.conf)partner uses the eventlistener loggerthe stdout-events plugin lives only in vuer-release; it is the consumer of the supervisor-stdout pip package
supervisor_<svc>_docker.confonly if it is a CUSTOMIZED eventlistener conf (contains stdout_events_enabled and the partner has the logger)a real partner override, not the stock program list

Evidence (don’t take it on faith — verify against merged partners):

  • The merged fundamenta / cofidis / magnet projects carry NO supervisor confs at all → confirms the stock confs are droppable.
  • The reviewed MVM migration (FKITDEV-8354-mvm-supervisor-config-dedup) keeps vuer_oss’s customized eventlistener conf + the logger, but its round-2 dedup DELETED vuer_css’s standard (byte-identical) conf. So: keep customized, drop stock. The decision rule is “deletable duplicate only if byte-identical to the source-package conf; otherwise it’s an intentional customization.”

janus PATCHED versions

Use the patched janus pins from settings.cfg, never the base default

Human guidance: “janusból a patchelt verziók kellenek 1.4.1 / 0.16.1” — the patched janus versions are required. Take each partner’s pin from its settings.cfg (VERSION + JANUS_VERSION_COMMIT). Do not copy the base default or a stale PR’s value.

janus VERSIONcommitpartners (this batch)
0.16.1af80f7ef262b231367cd85913afe244754572a52szerencsejatek, granit, barion, mbh, mkb-instant
1.4.1cc0fdca8b52916873f0280a03e15bf5fca0da906cib
  • Base component image janus is 1.4.1.
  • For contrast, the old merged fundamenta pins 0.13.4 / b8bebd941 — i.e. older partners legitimately carry older patched pins; always read settings.cfg, never assume.

Gen2 Dockerfile conversions vs legacy vuer_build

When translating a legacy vuer_build Dockerfile to the lean form, the recurring rewrites are:

Legacy vuer_buildGen2 vuer-release
multi-ARG + FROM harbor.techteamer.com/${PROJECT_NAME}/...ARG BASE_COMPONENT_IMAGE_TAG + FROM $BASE_COMPONENT_IMAGE_TAG
hardcoded python3.6 site-packages pathdynamic PYTHON_VERSION=$(python3 --version | sed ...) then build the path from it
sed -i "/user=/d" <supervisor conf>dropped (the underlying issue is fixed in the source)
--mount=type=bind to copy supervisor_stdout.pyCOPY to /tmp + cp into place + rm

OracleDB partners (RPM, not the committed tarball)

The Gen2 way to get Oracle Instant Client is the RPM install script — not a vendored tarball

Legacy partners (e.g. mkb-instant) committed a 29 MB oracle.tar.gz into the partner dir. vuer-release has no Git LFS, so this is a deprecated workaround. The Gen2 precedent is the merged kh project (projects/kh/components/vuer_oss/Dockerfile), which installs via RPM.

RUN --mount=type=bind,target=/install/,from=install-scripts \
    sh -x /install/install-oracleinstantclient.sh
# installs oracle-instantclient19.29-basiclite from the yum.oracle.com OL9 repo

Partner-specific Oracle network config (sqlnet.ora with AES256 / SHA256 encryption, etc.) goes into a version-decoupled /etc/oracle directory, pointed to by:

ENV TNS_ADMIN=/etc/oracle

Decoupling it from the client install path means an Oracle client version bump doesn’t move the config.

The batch outcome

Parent FKITDEV-8344 “vuer-release migráció”. 7 child tickets completed this session on worktree /Users/levander/coding/facekom/vuer-release/.worktrees/vuer-migrations (branch feature/FKITDEV-8344-vuer-release-migrations off origin/master). Nothing committed or pushed yet — the /fk-ticket analyze gate is armed; awaiting the user’s explicit “go”. No PRs created.

TicketPartnerShapeComponentsjanusNotes
FKITDEV-8356szerencsejateksimplevuer_css, vuer_oss0.16.1no logger; PROJECT_NAME has no suffix
FKITDEV-8357granitsimplevuer_css, vuer_oss0.16.1no logger
FKITDEV-8358barionsimplevuer_css, vuer_oss0.16.1no logger
FKITDEV-8365cibsimple + portalvuer_css, vuer_oss, portal_css1.4.1only 1.4.1 partner in batch
FKITDEV-8362mbheventlistenerjanus, rabbitmq, vuer_css, vuer_oss0.16.1logger + 2 customized confs kept
FKITDEV-8364mkb-instanteventlistener (5 svc)janus, rabbitmq, turn, vuer_css, vuer_oss0.16.1Oracle-via-RPM + sqlnet.ora; rabbitmq/turn keep chgrp customizations
FKITDEV-8359fundamenta———ALREADY MERGED (PR #26) — no work this session

Per-ticket detail worth keeping

  • 8356 / 8357 / 8358 (szerencsejatek, granit, barion): the simplest shape — vuer_css + vuer_oss only, no supervisor logger, all stock confs dropped. janus 0.16.1 / af80f7ef.
  • 8365 (cib): same simple shape plus a portal_css component. The only partner in the batch on janus 1.4.1 / cc0fdca8.
  • 8362 (mbh): an eventlistener partner — janus + rabbitmq + vuer_css + vuer_oss, with the supervisor-stdout logger and 2 customized supervisor confs kept (they contain stdout_events_enabled, so they are real overrides, not stock).
  • 8364 (mkb-instant): the heaviest — an eventlistener across 5 components (janus + rabbitmq + turn + vuer_css + vuer_oss), Oracle installed via RPM (the kh precedent) with a partner sqlnet.ora under /etc/oracle. rabbitmq and turn keep their chgrp customizations from the legacy Dockerfiles. See Open decisions flagged to the user for the three mkb-specific judgment calls.
  • 8359 (fundamenta): already migrated and merged as PR #26 — confirmed, no work needed.

Supersedes stale PRs

These migrations supersede vencelvarga’s stale open PRs #13 / #14 / #15 / #19 / #20 / #21. Those PRs are unsafe to merge as-is because they carry:

  • wrong janus versions (e.g. 0.13.4 / 1.2.4 instead of the patched 0.16.1 / 1.4.1),
  • cib unicode-corrupted filenames (zero-width U+200E LEFT-TO-RIGHT MARK embedded in filenames),
  • mkb’s 29 MB oracle.tar.gz committed into the repo (no Git LFS in vuer-release).

PR mapping (legacy stale → ticket)

The stale PRs map onto the same partners these tickets re-do. The new branch redoes them correctly in one tree rather than fixing six divergent PRs. Close the stale PRs in favor of the FKITDEV-8344 branch once it lands.

Open decisions flagged to the user

Three mkb-instant (8364) judgment calls need a human decision

  1. Oracle tarball → RPM switch. Dropping the legacy 29 MB oracle.tar.gz in favor of install-oracleinstantclient.sh (RPM). This follows the merged kh precedent but is a behavioral change from the legacy mkb Dockerfile — confirm acceptable.
  2. mkb rabbitmq supervisor_rabbitmq.conf not carried over. The legacy mkb Dockerfile never COPYd it, so it isn’t in the Gen2 tree either. Flagged in case it was an unnoticed legacy omission rather than intentional.
  3. mkb turn gained USER / CMD. Added per the Gen2 convention (lean Dockerfiles end with USER techteamer + CMD supervisord). Confirm this is desired for the turn component.

Quick reference

Recipe checklist (copy per partner)

  • project_env_values.json — org, PROJECT_NAME (keep suffix), SECURITY_NUMBER from settings.cfg
  • components/janus/component_env_values.json — VERSION + commit + BUILD_NUMBER (patched pin!)
  • components/vuer_oss/component_env_values.json — {JANUS_REPOSITORY, JANUS_VERSION_COMMIT}
  • Lean Dockerfile per component (FROM $BASE_COMPONENT_IMAGE_TAG, USER, CMD)
  • COPY temp_path.conf only where the partner has it
  • DROP stock supervisor_<svc>_docker.conf; KEEP logger apparatus + customized eventlistener confs
  • OracleDB → RPM via install-oracleinstantclient.sh; sqlnet.ora → /etc/oracle, ENV TNS_ADMIN=/etc/oracle
  • release/.gitkeep only (no release/N/release.json)
  • Verify janus pin against settings.cfg, not a stale PR

Graph View

Backlinks