Levandor

vuer-release release-cut recipe (autobuild → Harbor)

6 min read

vuer-release release-cut recipe (autobuild → Harbor)

How to cut a partner release in the modern vuer-release repo: add one release.json, commit it to master, push a <partner>@<N> tag, and the self-hosted autobuild.yml CI generates → builds → publishes the component images to Harbor. This is the reusable durable how-to; the worked example is nusz@13 (2026-07-03).

For Agents

  • Repo: TechTeamer/vuer-release (Gen2 lean release-orchestration repo — see vuer-release).
  • What the tool actually does (read from the TechTeamer/vuer-release-cli Python source): vuer-release-build-flow — notably that component source is cloned from TAG, not VERSION.
  • A release cut = one added file + one commit + one tag, committed directly to master (NOT via a PR).
  • The tag <partner>@<N> is what fires CI. Trigger = tag matching *@* and a changed path projects/*/release/*/release.json → .github/workflows/autobuild.yml on [self-hosted, docker].
  • The CLI is pinned by EXACT equality in .cliversion (1.0.3), and bumping it breaks CI — read vuer-release-cli-pinning before touching it or running the tool locally.
  • COMPONENT_LIST is a build set, not the customer’s stack — component-list-is-not-a-full-manifest. Omitting a component the partner runs silently drops it from the generated compose.
  • Distinct from the legacy manual vuer_build publish in release-process and from partner migration PRs in FKITDEV-8344-vuer-release-migration-batch.

The one-file recipe

For partner <partner>, cutting release number <N> (previous is <N-1>):

  1. Copy the previous release descriptor: projects/<partner>/release/<N-1>/release.json → projects/<partner>/release/<N>/release.json
  2. Bump in the new file:
    • top-level RELEASE_VERSION (the @<N> number)
    • RELEASE_VERSION inside DEFAULT_ARGS
    • TIMESTAMP
    • each component’s VERSION + TAG (→ new app version + source tag, e.g. 1.9.11.47 / nusz-1.9.11.47)
    • COMPONENT_LIST = the components that build (e.g. vuer_oss + vuer_css)
  3. Commit to master: Release: <partner>, version: <N>
  4. Tag + push: 
    git tag <partner>@<N>
git push origin master
git push origin <partner>@<N>
    The commit lands on master (clean fast-forward), not a branch. The tag push is what starts the build.

What the CI does (autobuild.yml)

.github/workflows/autobuild.yml runs on [self-hosted, docker], triggered by a pushed tag matching *@* and a changed projects/*/release/*/release.json. Two jobs:

  1. parse_tag — parses <partner>@<N>, resolves the release path. Fast (≈6 s green).
  2. build — downloads the release tool from TechTeamer/vuer-release-cli, then runs gen → build → publish login → publish push against release/<N>/release.json, pushing the built component images to Harbor.

Image tag anatomy

harbor.techteamer.com/<PROJECT_NAME>/<COMPONENT>:<VERSION>.<BUILD_NUMBER>-<SECURITY_NUMBER>

It is . before the build number, - only before the security number

Live example from the cib@1 run (2026-09-04): harbor.techteamer.com/cib-facekom/vuer_css:1.9.11.102.1-20221206 — VERSION 1.9.11.102, BUILD_NUMBER 1, SECURITY_NUMBER 20221206. Not <version>-<build>-<security>. Any note using the all-hyphen form is wrong.

The publish step is a distinct failure surface

publish login and publish push fail independently. Login succeeding tells you nothing about push rights — Harbor authorises per project. A first-ever cut for a partner is the moment this bites: the <PROJECT_NAME> Harbor project may never have been created. Worked failure: vuer-release cut — cib@1 (2026-09-04) — images built, login OK, docker push rejected, CalledProcessError … exit status 1.

What actually sets the pins in release.json

release-tool release create merges base/components/<c>/component_env_values.json then projects/<partner>/components/<c>/component_env_values.json (project wins) and prompts for every key with that value as the default. Whatever you confirm is written to release/<N>/release.json. So the component env files are the effective default but overridable at release time — not immutable, and not re-applied later.

Because this recipe hand-copies release/<N-1>/release.json instead of running release create, nothing overwrites your values: what you commit is exactly what builds. Keeping the new file in agreement with the current component_env_values.json is still good hygiene (it keeps the prompt defaults honest for anyone who does use release create), just not a correctness requirement.

vuer-release has essentially no commit-message ruleset

Verified 2026-09-04. vuer-release carries one ruleset — 12260273 “main-protect”, target ~ALL — containing exactly one rule: non_fast_forward. No commit-message pattern, no required PR, no tag rule.

  • Direct push to master is the norm and is not a bypass of anything.
  • The TechTeamer bracketed-ticket regex (techteamer-commit-message-ruleset) applies to vuer_oss/vuer_css customization/** + devel — not here.
  • So the commit subject is a convention choice. Both styles exist in history: the tool-generated Release: <partner>, version: <N> (CLI 1.0.3) and hand-made chore: [asscib-166] cib 1.9.11.102 release/1.

Gotchas

Check .cliversion before generating anything

.cliversion pins the CLI by exact equality, and CLI 1.0.3 vs 1.1.1 emit different release.json key sets. The hand-copy step above is safe precisely because it never runs the tool. If you do run it, run the pinned version — and see vuer-release-cli-pinning for the two local-install blockers.

Narrowed fetch refspecs in facekom clones

git ls-remote the repo before deciding FF / next tag number — local remote-tracking refs go stale (narrowed refspecs, no prune). Confirm master tip and the highest existing <partner>@N from the remote, not local.

Solo-author identity

The vuer-release clone’s default committer is andras.lederer@alpiq.com. Override to the solo-author identity Andras Lederer <25370292+wowjeeez@users.noreply.github.com> (git commit --author=…, no Co-Authored-By).

  • Failure handling: if CI fails after a tag is pushed, fix-forward to the next @N — do NOT delete pushed tags (precedent: nusz@8 was skipped, never created).
  • Watch a run: gh run watch <run-id> --repo TechTeamer/vuer-release. RTK mangles gh run view output → use rtk proxy gh … for raw output (see rtk-mangles-curl-and-pipes).

Relationship to the other release notes

  • release-process documents the legacy manual vuer_build publish (tag → build.sh → sign-partner.sh → Harbor) plus the per-client changelog/tag conventions on the customization branches. The source-tag step (tag vuer_oss + vuer_css <partner>-<version>, kept in sync) is shared; only the publish half differs (legacy build.sh vs modern autobuild).
  • FKITDEV-8344-vuer-release-migration-batch covers migrating a partner INTO vuer-release (the lean projects/<partner>/ layout). That note correctly says release/<N>/release.json is a release-tool artifact not added in a migration PR. No contradiction: you add release/<N>/release.json only when cutting a release (this note), committed directly to master, outside the migration PR.

Worked example — nusz@13

Added projects/nusz/release/13/release.json (COMPONENT_LIST = vuer_oss + vuer_css, VERSION 1.9.11.47, TAG nusz-1.9.11.47), commit 712000c on master (clean FF over d7ebb37), tag nusz@13 → autobuild CI run 28667229191 publishes app 1.9.11.47 to Harbor. Full record + payload: nusz-1.9.11.47.

Worked example — cib@1 (a FAILED cut)

projects/cib/release/1/release.json, commit ac8aa5cc55 on master, tag cib@1, autobuild run 33855979398. CIB’s first-ever modern cut, and it failed at the Harbor publish step. Read it for the failure shape, the image-tag anatomy, and the toolchain traps: cib-1.9.11.102.

vuer-release-cli-pinning · component-list-is-not-a-full-manifest · cib-1.9.11.102 · release-cut-mechanics · vuer-release-build-flow · nusz-1.9.11.47 · release-process · FKITDEV-8344-vuer-release-migration-batch · release-automation-design · client-registry

Graph View

Backlinks