fix(catalog): declare the Hermes project retirement #301

Merged

binjovi-bot merged 1 commit from feat/retire-hermes-project into trunk

2026-09-13 17:34:11 +00:00

sean commented

2026-09-13 17:33:45 +00:00

Owner

PR #297 removed the hermes project from the catalog and merged cleanly, but
the control plane has been refusing the new bundle on every poll ever since
and quietly continuing to serve the old one.

Binjovi.Control.PlanSource.validate_additive/2:

removed == declared -> :ok
declared == [] -> {:error, {:project_removal_not_supported, removed}}

A catalog that drops a project has to declare it. Nothing surfaced the refusal
anywhere I was looking -- binjovictl status binjovi-plans reported the release
as succeeded, and the raw bundle.json on trunk was correct. It showed up
indirectly, as seanfarm builds still selecting the retired
hermes-prerequisites group and failing on a render path the seanfarm change
deletes:

binjovi-gitops-validate: selected render path does not exist:
kubernetes/flux/infrastructure/hermes

Three seanfarm builds failed that way before I found this.

This key has to come back out

The declaration is transitional. Once this bundle is active, the next bundle
has removed == [] while declared is still ["hermes"], which is the
project_retirement_mismatch branch of the same function -- so the bundle after
this one would be refused the same silent way. A follow-up PR drops the key
immediately after this activates.

Worth noting for its own sake: a validation failure that leaves the previous
catalog serving, with no failed status on the release that caused it, is hard to
find. The symptom appeared two repositories away.

bash scripts/check passes.

https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA

PR #297 removed the `hermes` project from the catalog and merged cleanly, but the control plane has been **refusing the new bundle on every poll ever since** and quietly continuing to serve the old one. `Binjovi.Control.PlanSource.validate_additive/2`: ```elixir removed == declared -> :ok declared == [] -> {:error, {:project_removal_not_supported, removed}} ``` A catalog that drops a project has to declare it. Nothing surfaced the refusal anywhere I was looking -- `binjovictl status binjovi-plans` reported the release as succeeded, and the raw `bundle.json` on trunk was correct. It showed up indirectly, as seanfarm builds still selecting the retired `hermes-prerequisites` group and failing on a render path the seanfarm change deletes: ``` binjovi-gitops-validate: selected render path does not exist: kubernetes/flux/infrastructure/hermes ``` Three seanfarm builds failed that way before I found this. ### This key has to come back out The declaration is transitional. Once this bundle is active, the *next* bundle has `removed == []` while `declared` is still `["hermes"]`, which is the `project_retirement_mismatch` branch of the same function -- so the bundle after this one would be refused the same silent way. A follow-up PR drops the key immediately after this activates. Worth noting for its own sake: a validation failure that leaves the previous catalog serving, with no failed status on the release that caused it, is hard to find. The symptom appeared two repositories away. `bash scripts/check` passes. https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA

sean added 1 commit

2026-09-13 17:33:45 +00:00

fix(catalog): declare the Hermes project retirement

binjovi/ci Binjovi completed the frozen plan

Details

4d90ad6d3a

PR 297 removed the hermes project from the catalog and merged, but the
control plane has been refusing the new bundle on every poll ever since
and quietly serving the old one. PlanSource.validate_additive/2:

  removed == declared -> :ok
  declared == [] -> {:error, {:project_removal_not_supported, removed}}

A catalog that drops a project has to say so. Nothing surfaced the
refusal; it showed up as seanfarm builds still selecting the
hermes-prerequisites group and failing on a render path the seanfarm
change deletes:

  binjovi-gitops-validate: selected render path does not exist:
  kubernetes/flux/infrastructure/hermes

This declaration is transitional and must come out once this bundle is
active. On the bundle after that, removed is [] while declared is still
["hermes"], which is the project_retirement_mismatch branch of the same
function. A follow-up drops the key.

Claude-Session: https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA