Levandor

mando-cli GitLab CI — first pipelines and the single `release` branch flow

3 min read

mando-cli ran its first-ever GitLab pipelines today, after the project’s ci_config_path setting was cleared. Windows builds were dropped entirely and a single long-lived release branch flow replaced the previous shape.

For Agents

This is the GitLab pipeline for the mando-cli repo. It is distinct from the GitHub-Actions mirror in mando-cli-github-build-mirror and from the Rust service pipeline in Mando CI-CD.

Why nothing ever ran before

The GitLab project had a non-default ci_config_path pointing at a location with no pipeline definition, so pushes produced no pipelines at all. Clearing it made .gitlab-ci.yml take effect and the first pipelines ran.

Diagnostic

“The .gitlab-ci.yml is committed but no pipeline is created and no error is shown” almost always means a stale project-level ci_config_path (Settings → CI/CD → General pipelines), not a syntax problem.

Windows builds removed

Windows build jobs were removed entirely from mando-cli. (Compare Mando CI-CD, where the mando service still keeps container.win.*.Dockerfile variants and a PyMando Win Dev job.)

Single long-lived release branch flow

One long-lived release branch, with a clean split of responsibility:

BranchDoes
releasemints the tag, creates the GitLab release, and moves the latest pointer
mainbuilds and publishes versioned packages only — no tag, no release, no latest

So main is continuously publishing versioned artifacts, and promotion to “the release” is a single merge into release.

First release status — SHIPPED

v0.4.0 released (2026-08-05 evening)

Tag v0.4.0+2734905610, full pipeline green end to end: Version → musl builds → Publish + latest → Release. The MR !5 approval block below is resolved.

Historical: author cannot self-approve here

A group-level approval rule applies, and the author cannot satisfy it from the CLI — the approval has to come from another group member through the UI. No CI change unblocks this; it needs a human approver.

Two reusable GitLab CI gotchas from the Release job

The Release job failed once before the green run. Both causes generalize well beyond mando-cli.

dependencies: silently overrides needs: for artifact download

The Version job broadcasts PACKAGE_VERSION via artifacts: reports: dotenv. The Release job had both a needs: list and a dependencies: list. dependencies: wins for artifact fetching, so the Version job’s dotenv never arrived and the job ran with an empty tag=.

Rule

If a job declares dependencies:, that list — not needs: — decides which artifacts (including dotenv reports) are downloaded. Either omit dependencies: entirely and let needs: do both jobs, or make sure dependencies: names every artifact-producing upstream job. A dotenv var arriving empty with no error is the signature.

This is the same dotenv-broadcast pattern documented in bess-os-ci-components (python-setup exporting PROJECT_VERSION to downstream jobs) — the pattern works only when the download list is right.

Markdown backticks in release descriptions get shell-evaluated

release-cli runs inside a busybox wrapper, so backticks in a release description are treated as command substitution by the shell before release-cli ever sees them.

Rule

Keep GitLab release notes plain text — no backticks, no shell metacharacters. Code formatting in a release description is not worth the substitution hazard.

Graph View

Backlinks