The version the recipe pins, v1.0.0, does not exist #2

New issue

Open

opened 2026-09-28 00:09:13 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 00:09:13 -03:00

(Migrated from github.com)

The consuming recipe pins this component with

git clone --branch v1.0.0 https://github.com/keel-linux/unit-mariadb.git

and this repository has no tag and no release. Verified 2026-09-28:
gh api repos/Keel-Linux/unit-mariadb/tags returns 0, /releases returns 0,
and git ls-remote origin shows only HEAD, refs/heads/main and
refs/pull/1/head.

Since decision 0010's assembly step does not exist yet, that clone is the
assembly mechanism, so the documented build step fails with
fatal: Remote branch v1.0.0 not found in upstream origin. The only workaround
is cloning main, which is undocumented and unpinned.

There is a second, quieter problem behind it. buildtasks/bin/layer-lib
(layer_unit_version) takes the committed version file first and treats it
as authoritative; only a unit without one falls through to git HEAD or a
content digest. Because version is committed and reads 1.0.0, any tree
records mariadb@1.0.0 in the manifest — main, a branch, or a locally edited
copy. So the manifest cannot distinguish the pinned component from whatever
happened to be in unit.d/.

Closes when the pin resolves to something immutable and the manifest records
which tree was actually used. Tagging is the obvious half; say what happens to
the committed version file, since with it present the manifest entry is not a
pin.

The consuming recipe pins this component with git clone --branch v1.0.0 https://github.com/keel-linux/unit-mariadb.git and this repository has no tag and no release. Verified 2026-09-28: `gh api repos/Keel-Linux/unit-mariadb/tags` returns `0`, `/releases` returns `0`, and `git ls-remote origin` shows only `HEAD`, `refs/heads/main` and `refs/pull/1/head`. Since decision 0010's assembly step does not exist yet, that clone **is** the assembly mechanism, so the documented build step fails with `fatal: Remote branch v1.0.0 not found in upstream origin`. The only workaround is cloning `main`, which is undocumented and unpinned. There is a second, quieter problem behind it. `buildtasks/bin/layer-lib` (`layer_unit_version`) takes the committed `version` file first and treats it as authoritative; only a unit without one falls through to git HEAD or a content digest. Because `version` is committed and reads `1.0.0`, **any** tree records `mariadb@1.0.0` in the manifest — `main`, a branch, or a locally edited copy. So the manifest cannot distinguish the pinned component from whatever happened to be in `unit.d/`. Closes when the pin resolves to something immutable and the manifest records which tree was actually used. Tagging is the obvious half; say what happens to the committed `version` file, since with it present the manifest entry is not a pin.