Partner overlay Dockerfiles in vuer_build pin the app image by version but COPY the supervisor conf unversioned from main. Conf and app code are therefore decoupled, so any change to a command= line (e.g. the .js → .ts entrypoint rename of FKITDEV-8387) breaks rebuilds of older release tags and breaks every partner whose customization/* branch has not yet merged devel. This is a versioning mismatch, not a merge-ordering problem.
Release blocker
Do not merge a
command=node <entry>.<ext>change intovuer_build/vuer-releaseon the assumption that “merge the code repos first” makes it safe. The overlay conf is not version-pinned — the moment it lands onmain, every build of every release tag (including old ones) picks it up.
The mechanism
vuer_build/partner/<client>/vuer_oss/Dockerfile:
FROM harbor.…/vuer_oss:${VUER_VERSION}… # app image: VERSION-PINNED
COPY supervisor_vuer_oss_docker.conf … # overlay conf: from main, UNVERSIONEDSo:
- The app layer comes from a tagged, immutable image.
- The conf layer comes from whatever is on
vuer_build’s default branch at build time.
A rebuild of release 1.9.11.NN six months from now gets the old app plus today’s conf.
Consequences of flipping the confs
- Old release tags stop rebuilding. An older app image still ships
server.js; today’s conf sayscommand=node server.ts→MODULE_NOT_FOUND→ supervisord crash-loop. - ~94
origin/customization/*branches still carry.js. Each partner breaks on its next build until it merges devel. The break is per-partner and time-staggered, which makes it look like a random partner regression rather than one coordinated change. - Merge ordering cannot fix either — there is no ordering in which an unversioned file is correct for two different app versions simultaneously.
Mitigations (pick one)
| Option | What it does | Cost |
|---|---|---|
| Hold the merges | Keep the vuer_build / vuer-release conf flip unmerged until the first release tag containing the rename is cut, then merge | Simple; needs discipline + a tracking ticket |
| Delete redundant overlay confs | Partners then inherit the base image’s symlink to the app’s own conf (install/configure-app.sh symlinks the source package’s supervisor*.conf) → the conf becomes version-pinned along with the app | Only valid for overlays that are byte-identical / redundant — see the decision rule in FKITDEV-8354-mvm-supervisor-config-dedup |
| Make overlays release-aware | Version/branch the overlay confs alongside the app | Largest change; correct long-term fix |
Customization-branch merge hazards
Two partner branches carry conflicting edits that make the eventual devel merge non-trivial:
customization/kh— modifies both supervisor confs → merge conflicts on the conf flip.customization/nusz— modifiesserver.jsandcron.js→ the merge is a rename + modify on both files.
Related
- FKITDEV-8387 — the entrypoint TypeScript rename that surfaced this
- entrypoint-rename-blast-radius — the 95-conf footprint of any entrypoint rename
- FKITDEV-8354-mvm-supervisor-config-dedup — how partner supervisor overlays layer, and when one is deletable
- vuer-release-build-flow — how release tags and component images are built
- customization-branches · release-process
- vuer_oss · vuer_css · portal_css