Levandor

cib-1.9.11.102 · ASSCIB-166 / FKITDEV-9197

10 min read

cib-1.9.11.102 · ASSCIB-166 / FKITDEV-9197

Per-release tracking hub for the CIB VUER release 1.9.11.102 — a pure core-update release (eleven months of devel drift, 334 commits, 212 tickets, zero partner commits since .101). The payload work is documented in FKITDEV-9197; this note records the merge and tag outcome of 2026-09-03 and the consequences that outlive the release.

For Agents

  • Tagged 2026-09-03. Components are vuer_oss + vuer_css only — per ASSCIB-166’s Komponensek field. portal_css is deliberately out of the train.
  • Both PRs were squash-merged, not merge-committed → devel is no longer an ancestor of customization/cib. This is the single most consequential fact in this note; see Squash merge — devel is no longer an ancestor of customization/cib and squash-merge-erases-partner-devel-ancestry.
  • Tagged content is safe and byte-identical to what was reviewed; only the history shape changed.
  • 2026-09-04: CIB’s first-ever vuer-release cut cib@1 was made — and it FAILED at the Harbor publish step. Images built fine, Harbor login succeeded, docker push was rejected. BLOCKED pending a Harbor admin. See vuer-release cut — cib@1 (2026-09-04).
  • Still open: Docker image publish, the missing .102 changelog entry, and TjK cleanup (see Open after tagging).
  • Facts dated 2026-09-03 were live-verified via the GitHub API that day; the 2026-09-04 section was live-verified on 2026-09-04.

Merge outcome (2026-09-03)

RepoPRMerged (UTC)State
vuer_oss#812613:10:49Zmerged (squash)
vuer_css#315212:55:36Zmerged (squash)
portal_css#712—OPEN — intentionally not in this release

The portal_css PR is left open on purpose: ASSCIB-166 scopes the release to vuer_oss + vuer_css. The portal merge is green either way and can land on its own schedule; note also that portal_css runs its own version train (cib-1.4.0.74 was its last CIB tag) and never carries a cib-1.9.11.* number.

Tags (2026-09-03)

Both tags are annotated, tagger Andras Lederer, message the bare version string 1.9.11.102\n.

RepoTagTarget commit
TechTeamer/vuer_osscib-1.9.11.10212a8a9e328221829ae6d383fd5e23eda9cf81a38
TechTeamer/vuer_csscib-1.9.11.102ca60fac34ac95b661336587b455924ab55e52def

Tags were created through the GitHub API, not a local push

Deliberate. The vuer_css clone has a narrowed fetch refspec, so local refs go stale silently and a locally-created tag can end up pointing at the wrong commit — see narrowed-fetch-refspec-stale-devel-merge. Creating the tag objects server-side against explicitly resolved SHAs sidesteps the whole trap.

The annotated-tag convention started at .101

TagKindMessageTaggerDate
cib-1.9.11.100lightweight———
cib-1.9.11.101annotated1.9.11.101\nSzabó Márton2026-05-29
cib-1.9.11.102annotated1.9.11.102\nAndras Lederer2026-09-03

.102 matches .101 exactly. Do not take .100 as the pattern — the convention changed at .101.

vuer-release cut — cib@1 (2026-09-04)

CIB’s first-ever modern cut. Every prior CIB release, .101 included, was built through the legacy vuer_build path — so .102 is also the moment CIB’s build path changes. client-registry has been corrected accordingly.

FieldValue
Commitac8aa5cc55 on TechTeamer/vuer-release master
Messagechore: [asscib-166] cib 1.9.11.102 release/1
AuthorAndras Lederer (wowjeeez), solo-author
Diffadds projects/cib/release/1/release.json only
Tagcib@1 (pushed)
Autobuild run33855979398

The descriptor

COMPONENT_LIST = vuer_oss + vuer_css, both VERSION 1.9.11.102 / TAG cib-1.9.11.102 / BUILD_NUMBER 1.

Other values: NODE_VERSION 24.15.0, SECURITY_NUMBER 20221206, UID/GID 1000, BUNDLE_IMAGE false, PROJECT_NAME cib-facekom.

cib@1 FAILED — at "Project images publish to Registry"

  • parse_tag — success.
  • build — images built successfully, Harbor login successful, then failed at the publish step:
CalledProcessError: Command '['docker','push',
  'harbor.techteamer.com/cib-facekom/vuer_css:1.9.11.102.1-20221206']'
  returned non-zero exit status 1

The build is not the problem. Everything up to and including the Harbor login worked; only the push was rejected.

Image tag anatomy — CORRECTION

The tag in that error is 1.9.11.102.1-20221206, i.e.

<VERSION>.<BUILD_NUMBER>-<SECURITY_NUMBER>

a dot before the build number, a hyphen only before the security number. Not <version>-<build>-<security>. Correct any note that says otherwise.

Root cause — HYPOTHESIS, not confirmed

Needs a Harbor admin — no Harbor credentials were available locally

Strong hypothesis: the Harbor project cib-facekom does not exist, or the robot account lacks push rights on it.

Supporting (circumstantial, not proof):

  • Harbor login succeeded → the credentials themselves are valid; the rejection is project-scoped, not auth-wide.
  • The same self-hosted runner pushed nusz@18 successfully on 2026-09-03 → the runner and its Harbor config are working.
  • This is CIB’s first automated push to cib-facekom — .101 and everything before it went through legacy vuer_build. Confirmed by direct grep on 2026-09-04: vuer_build contains no docker push and no docker login anywhere (vuer-build-never-pushes). The legacy toolchain cannot publish to Harbor at all, so nothing in the repo establishes that the CI robot has ever had write access to cib-facekom.

Why non-existence could NOT be checked: Harbor’s API returns [] unauthenticated for every project, including ones that certainly exist. An empty response is therefore not evidence the project is missing. No Harbor credentials were available locally.

Record this as a hypothesis. Do not write it into a ticket as fact until an admin confirms the project’s existence and the robot’s push permission.

cib@2 — prepared, NOT committed

projects/cib/release/2/release.json exists in the local clone only — uncommitted, untagged, held pending the Harbor fix. Its one substantive change over @1 is adding portal_css at 1.4.0.74.

The justification is CIB's own PROD compose, not precedent from other partners

vuer_build/partner/cib/docker-compose.yml — the file CIB PROD actually pulls — contains exactly three image: lines, all harbor.techteamer.com/${PROJECT_NAME}/…:

servicenotes
vuer_css${VUER_VERSION}.${VUER_BUILD_NUMBER}
vuer_oss${VUER_VERSION}.${VUER_BUILD_NUMBER}
portal_cssseparate ${PORTAL_VERSION}.${PORTAL_BUILD_NUMBER} vars
  • portal_css is REQUIRED in the bundle — cib@1 without it leaves CIB unable to deploy a complete stack, since release-tool gen builds the delivered compose from COMPONENT_LIST.
  • There is NO janus image: line, so omitting janus is correct for CIB — it rides as JANUS_VERSION_COMMIT on the vuer_oss entry, not as a component. Contrast the Raiffeisen case where janus is deployed and was still omitted: SLARAFIPI-83.

Read 2026-09-04 directly from the local vuer_build clone.

General rule and the fleet-wide measurements: component-list-is-not-a-full-manifest.

Note this does not put portal_css into the .102 source-tag train — portal_css keeps its own version line (cib-1.4.0.*) and #712 is still open. @2 ships the existing portal version so the generated compose is complete.

Failure handling on vuer-release is fix-forward

Do not delete cib@1. The convention is to cut the next @N (precedent: nusz@8 was skipped and never created). See vuer-release-cut-recipe.

Toolchain findings from this cut

Running the CLI locally exposed several independent breakages — .cliversion is an exact-equality pin at 1.0.3, the current CLI 1.1.1 renamed its release asset so bumping the pin would break the runner, and 1.0.3’s own pyproject.toml is invalid TOML. Full detail: vuer-release-cli-pinning.

vuer-release has essentially no branch protection

Ruleset 12260273 “main-protect”, target ~ALL, contains exactly one rule: non_fast_forward. No commit-message pattern, no required PR, no tag rule. Direct push to master is the norm here.

This is the opposite of the vuer repos: the TechTeamer bracketed-ticket commit regex (techteamer-commit-message-ruleset) applies to vuer_oss/vuer_css customization/** + devel, not to vuer-release. The chore: [asscib-166] … style on ac8aa5cc55 is convention, not enforcement.

The 1.9.11.102 changelog was never written

Open, deliberately not fixed

customization/RELEASE.MD on customization/cib still tops out at ## [1.9.11.101] - 2026-05-29 in BOTH vuer_oss and vuer_css. Independently verified via the GitHub API on 2026-09-04.

Because the source tags cib-1.9.11.102 already point at the branch tips, any changelog commit made now lands after the tag — the tagged trees would not contain it.

Decision taken 2026-09-04: FLAG ONLY, do not touch. Carried as an open item on the release ticket.

This differs from the NÚSZ .48 flow, where the changelog was committed first and the source tag was then pointed at the changelog commit. For CIB the ordering was lost, and re-tagging is not worth it.

Squash merge — devel is no longer an ancestor of customization/cib

The highest-impact finding of the cut

Both PRs were squash-merged. Each resulting commit has exactly one parent:

  • vuer_oss 12a8a9e3 → parent 8abcc4c733
  • vuer_css ca60fac3 → parent b043527c72 (which was itself the cib-1.9.11.101 tag target for css)

A real merge commit would have two. So 334 commits / ~11 months of devel history collapsed into a single commit per repo, and devel is not reachable from customization/cib.

Consequence

The next devel → customization/cib update will not recognise these eleven months as already merged. Git will re-present all of it as new changes, with heavy conflicts — conflicts against code that is, in content terms, already there. Whoever runs the next CIB devel update must expect this and plan for it (see squash-merge-erases-partner-devel-ancestry for the reusable version and mitigation options).

Content safety was verified before tagging

The squash commits’ trees are byte-identical to the reviewed PR head trees, so the tagged content is exactly what was reviewed and tested:

RepoTree SHASquash commitReviewed PR head
vuer_ossdf853239b1755be56983cd691b5f980905b81bca12a8a9e386f7dab01d
vuer_css38079f89c7d524185a5c0b265f646c2c6798e634ca60fac383e4adbd2c

Only the history shape differs. The shipped bits do not.

Open question — not verified

Whether earlier CIB releases were merged with real merge commits rather than squashes was not checked. Do not assume .101 and before used merge commits; that needs its own verification pass before anyone concludes this is a new regression in CIB’s release practice.

Open after tagging

  • BLOCKER — Harbor publish. cib@1 built the images and logged in, then had docker push harbor.techteamer.com/cib-facekom/vuer_css:1.9.11.102.1-20221206 rejected. Needs a Harbor admin to confirm the cib-facekom project exists and the robot account has push rights. See vuer-release cut — cib@1 (2026-09-04).

  • cib@2 descriptor prepared at projects/cib/release/2/release.json in the local clone — uncommitted, holding for the Harbor fix; adds portal_css 1.4.0.74.

  • ASSCIB-166 “GitHub tagek” section is fillable now; the “Docker Image-ek” section is blocked until a publish succeeds.

  • 1.9.11.102 changelog entry missing in both repos — see The 1.9.11.102 changelog was never written.

  • Unresolved: how the base release version is selected. The Dockerfiles take ARG BASE_COMPONENT_IMAGE_TAG, injected by release-tool; it is not named in release.json.

  • TjK (Tesztelési jegyzőkönyv) is incomplete:

    • tester / verifier name fields are still blank;
    • date mismatch — the document says 2026.08.13, the evidence is dated 2026.08.17.

    See tesztjegyzokonyv-generation-flow. Note CIB’s TjK shape has never been verified (partners.json has priorShape: null) — an open item carried over from FKITDEV-9197.

  • portal_css #712 remains open, out of train, undated.

Evidence for FKITDEV-9230 can only be the spreadsheet

The CIB advanced report page /reports-advanced has no chart and no on-screen table — the xlsx export is its only output. This is source-verified and it constrains what test evidence for the FKITDEV-9230 async-filter fix can possibly look like: a workbook, never a screenshot of the app. Full detail: cib-reports-advanced-is-export-only.

Graph View

Backlinks