coulomb/activity-core
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Harden SBOM retries and align hub evidence
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Build and Publish Container Image / build-and-push (push) Successful in 21s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a028de-e2c8-7732-8521-46a7fc5db82f
This commit is contained in:
tegwick 2026-08-22 22:51:13 +02:00
parent 0f573c4378
commit 3b3e1a1ff0
17 changed files with 941 additions and 140 deletions
Download patch file Download diff file Expand all files Collapse all files

26
docs/runbook.md
View file

@ -595,9 +595,15 @@ export FORGEJO_TOKEN=$(bao kv get -field=API_TOKEN platform/workloads/forgejo/fo
fleet-wide `for_each: context.repos.repos` emitted 75 tasks on 2026-08-17 and
must not be re-enabled. The bounded replacement is `daily-sbom-catchup`, active
weekdays at 09:15 Europe/Berlin. It makes one ranked sbom-nexus request,
processes at most three terminal ingest/skip outcomes, and emits no tasks. Two
production proof fires on 2026-08-22 processed six distinct repositories as
documented `no-checkout` skips with zero task spawns; see
records that read-only selection in workflow history, and processes at most
three terminal ingest/skip outcomes in a dedicated heartbeat-enabled activity.
Retries retain the same fixed targets and resume acknowledged outcomes. Each
write carries a stable per-run/per-repository `Idempotency-Key`; an ambiguous
response fails the activity and is not converted into a synthetic skip. Until
sbom-nexus enforces that key, a worker crash after a committed POST but before
the next heartbeat remains a possible duplicate-write window. The automation
emits no tasks. Two production proof fires on 2026-08-22 processed six distinct
repositories as documented `no-checkout` skips with zero task spawns; see
`docs/evidence/ACTIVITY-WP-0030-daily-sbom-catchup-2026-08-22.md`.
`weekly-coding-retro` follows the same cron -> context resolver -> per-repo task
@ -617,8 +623,18 @@ when the workflow completes cleanly twice in a row.
## Ops inventory evidence posture
The current accepted live backend for activity-core ops inventory probes is
State Hub progress with `event_type=ops_inventory_probe`.
Hub-core has been the production runtime authority since 2026-08-21. The
Railiance projection of the (still disabled) ops-inventory probe now writes
sanitized evidence through canonical `port.events.interaction` using sink type
`hub-core-interaction-event`. `HUB_CORE_BASE_URL` targets the in-cluster
hub-core runtime. No widget mapping or Core Hub runtime token is required.
The sink wraps the observation as catalog event `hub.interaction.recorded`,
keeps the logical observation name in `payload.reported_event_type`, and reads
the `interaction_events` projection after append to verify persistence. The old
`core-hub-interaction-event` `/api/v2` sink remains implemented for rollback
compatibility during CORE-WP-0010 stabilization, but is no longer the Railiance
probe configuration.
Inter-Hub / ops-hub per-entity submission remains intentionally deferred until
all of these are true: