Skip to content

The documentation describes 0.1.0a7, and the tag trap that cutting it found - #18

Merged
FlagshipDev merged 1 commit into
mainfrom
publish/2026-08-07-fd2f126
Aug 7, 2026
Merged

The documentation describes 0.1.0a7, and the tag trap that cutting it found#18
FlagshipDev merged 1 commit into
mainfrom
publish/2026-08-07-fd2f126

Conversation

@FlagshipDev

Copy link
Copy Markdown
Contributor

Post-release, in the order docs/releasing.md requires because each step needs the one before it: ask
the new image what it accepts — 26 commands, read off ghcr.io/easybytehub/hullwork:0.1.0a7 rather
than off this checkout — then move the five pins in README.md, docker-compose.yml,
docs/install.md and PRIVACY.md.

Doing it the other way round fails tests/test_the_documentation_describes_the_published_artefact.py
in both directions, which is the whole reason the recording is stored rather than the sequence trusted.

And a warning earned the hard way

docs/releasing.md now carries the trap that cutting this release walked into: the tag goes on the
public commit, and git push <remote> vX does not do that.

Development happens on a private forge and this repository is a derivation of it, so a tag created in
the development checkout points at a commit this repository does not have. Pushing it brings the
objects the tag needs — and for about ten minutes the withheld paths were browsable at that ref.

No credential was exposed: the deployment's environment file is not tracked. What was exposed is the
internal item ledger and the deployment's own compose, which name a private address, a port and two
hostnames — exactly the set the publish script guards.

Two things made it worse before they made it better, and both are in the warning: the tag ruleset
refused the deletion, which is the rule working as intended, and the tag push started two
release runs — one building from the private commit. That one was cancelled inside a minute and
published nothing. The release came from the derived commit: the image has no work/, no deploy/ and
no scripts/, and gh attestation verify passes on it.

The procedure now spells out the three API calls that create a tag on this repository pointing at its
own main. The four earlier tags were cut that way and none of them exposes anything.

Signed-off-by: Javier Miralles Rancaño 68760931+FlagshipDev@users.noreply.github.com

… found

Post-release, in the order `docs/releasing.md` requires because each step needs the one before it: ask
the new image what it accepts — 26 commands, read off `ghcr.io/easybytehub/hullwork:0.1.0a7` rather
than off this checkout — then move the five pins in `README.md`, `docker-compose.yml`,
`docs/install.md` and `PRIVACY.md`.

Doing it the other way round fails `tests/test_the_documentation_describes_the_published_artefact.py`
in both directions, which is the whole reason the recording is stored rather than the sequence trusted.

## And a warning earned the hard way

`docs/releasing.md` now carries the trap that cutting this release walked into: **the tag goes on the
public commit, and `git push <remote> vX` does not do that.**

Development happens on a private forge and this repository is a *derivation* of it, so a tag created in
the development checkout points at a commit this repository does not have. Pushing it brings the
objects the tag needs — and for about ten minutes the withheld paths were browsable at that ref.

No credential was exposed: the deployment's environment file is not tracked. What was exposed is the
internal item ledger and the deployment's own compose, which name a private address, a port and two
hostnames — exactly the set the publish script guards.

Two things made it worse before they made it better, and both are in the warning: the tag ruleset
**refused the deletion**, which is the rule working as intended, and the tag push started **two**
release runs — one building from the private commit. That one was cancelled inside a minute and
published nothing. The release came from the derived commit: the image has no `work/`, no `deploy/` and
no `scripts/`, and `gh attestation verify` passes on it.

The procedure now spells out the three API calls that create a tag on this repository pointing at its
own `main`. The four earlier tags were cut that way and none of them exposes anything.

Signed-off-by: Javier Miralles Rancaño <68760931+FlagshipDev@users.noreply.github.com>
@FlagshipDev
FlagshipDev enabled auto-merge (squash) August 7, 2026 13:02
@FlagshipDev
FlagshipDev merged commit fcf4373 into main Aug 7, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant