Levandor

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

5 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].
  • 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 push against release/<N>/release.json, pushing the built component images to harbor.techteamer.com/<project>/<component>:<version>-<…>.

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.

Gotchas

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.

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