Follow-up from ci#365 (compounding problem 4)
The metanorma-cli v1.16.9 rubygems created_at (~01:41 local time) predates the release/do-release workflow run (~15:35 local time) that should have published it — an ordering gap that undermines the "when did this gem actually land on rubygems" question the failsafe green-dashboard needs to answer reliably.
Why this matters
The failsafe green-dashboard (the observability programme this SSOT cluster is building) needs to trust the following relationship:
release workflow run success → gem published on rubygems → GH Release created
If the rubygems created_at predates the workflow run that supposedly published it, one of two things is true:
- A second (undocumented) publish path exists — some other mechanism reserved or published the version out-of-band with the workflow. Every gem's true publish provenance becomes ambiguous.
- rubygems.org reserves version numbers before publish — the
created_at reflects reservation, not publication. In which case the API field name is misleading and the dashboard needs a different field to trust.
Either way, a dashboard whose "published on rubygems" signal comes from a field whose semantics are unclear can't be a failsafe.
What this ticket is
Reconcile the timeline. Steps:
- Verify the observation on 1-2 more recent releases (e.g. metanorma-core v0.2.2, metanorma-ietf v3.7.9) to confirm it's a pattern not a one-off.
- Determine whether rubygems.org has a documented "reservation vs publish" distinction on gem versions.
- If reservation exists as a separate concept, identify the correct API field/endpoint that reflects the actual publish moment.
- Update any dashboard-facing "did this gem publish?" check to use the correct field.
- If NO reservation concept exists, hunt down the second publish path (workflow, action, script — anything that touches rubygems for these gems).
Priority
Medium — not blocking any release, but the failsafe programme's core "green means published" invariant needs a trustworthy "did it publish?" signal to build on. Currently we're building on sand there.
Related
🤖
Follow-up from ci#365 (compounding problem 4)
The metanorma-cli v1.16.9 rubygems
created_at(~01:41 local time) predates the release/do-release workflow run (~15:35 local time) that should have published it — an ordering gap that undermines the "when did this gem actually land on rubygems" question the failsafe green-dashboard needs to answer reliably.Why this matters
The failsafe green-dashboard (the observability programme this SSOT cluster is building) needs to trust the following relationship:
If the rubygems
created_atpredates the workflow run that supposedly published it, one of two things is true:created_atreflects reservation, not publication. In which case the API field name is misleading and the dashboard needs a different field to trust.Either way, a dashboard whose "published on rubygems" signal comes from a field whose semantics are unclear can't be a failsafe.
What this ticket is
Reconcile the timeline. Steps:
Priority
Medium — not blocking any release, but the failsafe programme's core "green means published" invariant needs a trustworthy "did it publish?" signal to build on. Currently we're building on sand there.
Related
🤖