Levandor

COMPONENT_LIST is not a complete manifest of what the customer runs

5 min read

COMPONENT_LIST is not a complete manifest of what the customer runs

COMPONENT_LIST in projects/<partner>/release/<N>/release.json is the set of components THIS release builds and publishes — not an inventory of the partner’s deployment. Measured across all 18 partners’ latest releases on 2026-09-04 while cutting cib@1.

Correction

An earlier analysis concluded that release.json is always “a complete manifest of what the customer runs”. That is not a reliable rule. A component directory existing under projects/<partner>/components/ does not mean the component is in COMPONENT_LIST, and COMPONENT_LIST does not enumerate the partner’s running stack.

For Agents

Two facts that pull in opposite directions, and you need both:

  1. COMPONENT_LIST is a build set — partners routinely omit components they demonstrably run.
  2. release-tool gen builds the customer’s docker-compose FROM COMPONENT_LIST — so omitting a component the customer runs produces a compose file with no such service.

Consequence: an omission is not “harmless scoping”, it is a silent delivery gap. See The failure mode this creates.

Evidence (measured 2026-09-04)

  • janus has a component dir in 12 partners but is in COMPONENT_LIST for only 3 — barion, cofidis, kh. Partners with the dir that omit it include nusz, raiffeisen, magnet, szerencsejatek, fundamenta, microsec, mkb-instant, dap.

  • mkb-instant has rabbitmq and turn component dirs and ships neither.

  • Four manifests contain no vuer_oss/vuer_css at all — they are single-component bundles. Nobody runs a FaceKom install that is one report engine, so these alone disprove the universal-manifest reading:

    FileCOMPONENT_LIST
    projects/demo-facekom/release/6/release.json['report-engine']
    projects/demo-project/release/1/release.json['resource-manager']
    projects/demo-project/release/2/release.json['resource-manager']
    projects/demo-project/release/3/release.json['resource-manager']

  • 12 of the 18 partners’ latest cuts ship exactly vuer_oss + vuer_css.

  • Every partner that ships portal_css does so at a static version across releases — e.g. unicredit-srb @1–@5 all carry portal_css 2.2.0.9. The portal is rebuilt only when it changes, and simply repeats otherwise.

Component NAME entry counts across every manifest in the repo

Counted with Python over the parsed JSON (not a shell pipe — rtk zeroes | wc -l, which produced a wrong intermediate figure on the first attempt). Verified 2026-09-04.

count
projects/*/release/*/release.json files total91
…of which use a COMPONENT_LIST90
…excluding the two new cib cuts (cib@1, cib@2)88

Component entry counts over those 88 files:

NAMEentries
vuer_oss84
vuer_css84
portal_css8
janus5
resource-manager3
report-engine1

These are ENTRY counts, not file counts

84 is the number of vuer_oss entries, i.e. 84 of the 88 manifests carry it. The missing 4 are precisely the single-component bundles listed above — no contradiction. Including the two cib cuts the totals read 86 / 86 / 9, a clean +1/+1/+1, which is what confirms the count is self-consistent.

The long tail is the finding: portal_css, janus, resource-manager and report-engine together account for 17 entries across 88 manifests.

Not every release.json even HAS a COMPONENT_LIST

projects/equilor/release/1/release.json uses an older, entirely different schema

It has no COMPONENT_LIST key at all. Its top-level keys are lowercase:

default_args · docker_registry · git_remote · project · project_args · services · timestamp

This is a legacy manifest format still present in the repo. equilor has exactly one release, which is why it is easy to miss.

Any script that iterates all release.json files must handle it — reading release_json["COMPONENT_LIST"] unguarded raises KeyError on this one file. (Hit for real on 2026-09-04.) Relevant to the tooling in release-pipeline-automation-spec.

The failure mode this creates

Because gen derives the shipped compose from COMPONENT_LIST, a component the partner runs but that is missing from the list is never built, never published, and absent from the delivered compose — with no error anywhere in the pipeline.

This is exactly the Raiffeisen janus story: janus is absent from COMPONENT_LIST in all ten Raiffeisen release manifests, so no janus image has ever been built or shipped to Raiffeisen — they remain on 0.13.4 while the build definition claims otherwise. The JANUS_VERSION_COMMIT field that looks like a janus pin is an attribute on the vuer_oss component (what it is built against), not a janus image. Full detail: janus-memory-leak-rca.

Practical rule when cutting a release

  1. Do not infer the shipped set from projects/<partner>/components/ — it over-counts.
  2. Do not infer the partner’s running stack from COMPONENT_LIST — it under-counts.
  3. Decide the list explicitly, against the release issue’s Komponensek field and against what the partner is known to run.
  4. If a component the partner runs is omitted deliberately (because it did not change), be aware the generated compose will not contain it.

Worked decision — CIB

cib@1 shipped vuer_oss + vuer_css only. Decision taken 2026-09-04: cib@2 adds portal_css at 1.4.0.74.

The decision rests on CIB’s own production compose, not on precedent from other partners. vuer_build/partner/cib/docker-compose.yml — the file CIB PROD actually pulls from — contains exactly three image: lines: vuer_css, vuer_oss, portal_css, all under harbor.techteamer.com/${PROJECT_NAME}/…. So:

  • portal_css is REQUIRED in the bundle. PROD pulls it; cib@1 without it leaves CIB unable to deploy a complete stack.
  • janus is CORRECTLY excluded. There is no janus image: line in CIB’s compose — it rides as JANUS_VERSION_COMMIT on the vuer_oss entry, exactly the attribute-not-component distinction described above.
  • portal_css interpolates its own ${PORTAL_VERSION}.${PORTAL_BUILD_NUMBER} vars, separate from ${VUER_VERSION}.${VUER_BUILD_NUMBER} — consistent with it running its own version train (cib-1.4.0.*).

The descriptor is prepared but not committed or tagged — held behind the Harbor blocker. See vuer-release cut — cib@1 (2026-09-04).

Generalisable check

When deciding a partner’s COMPONENT_LIST, read the partner’s deployed compose (vuer_build/partner/<client>/docker-compose.yml for legacy-origin partners) and count the image: lines. That answers “what does the customer actually pull?” directly, which is the question COMPONENT_LIST does not answer on its own.

Graph View

Backlinks