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 into vuer_build / vuer-release on the assumption that “merge the code repos first” makes it safe. The overlay conf is not version-pinned — the moment it lands on main, 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, UNVERSIONED

So:

  • 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

  1. Old release tags stop rebuilding. An older app image still ships server.js; today’s conf says command=node server.tsMODULE_NOT_FOUND → supervisord crash-loop.
  2. ~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.
  3. 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)

OptionWhat it doesCost
Hold the mergesKeep the vuer_build / vuer-release conf flip unmerged until the first release tag containing the rename is cut, then mergeSimple; needs discipline + a tracking ticket
Delete redundant overlay confsPartners 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 appOnly valid for overlays that are byte-identical / redundant — see the decision rule in FKITDEV-8354-mvm-supervisor-config-dedup
Make overlays release-awareVersion/branch the overlay confs alongside the appLargest 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 — modifies server.js and cron.js → the merge is a rename + modify on both files.