Skip to content

chore: bump the cluster context pin - #36

Merged
ExtraToast merged 1 commit into
mainfrom
chore/bump-cluster-context
Aug 27, 2026
Merged

chore: bump the cluster context pin#36
ExtraToast merged 1 commit into
mainfrom
chore/bump-cluster-context

Conversation

@ExtraToast

Copy link
Copy Markdown
Contributor

Control bump for JorisJonkers-dev/workspace#53. One repo first, deliberately.

State

Every consumer is pinned to e839b908…, published 2026-08-26 12:32. The context has been republished three times since:

2026-08-27 00:55  95dc39fc6956   <- this PR
2026-08-27 00:23  fbfa783528c4
2026-08-26 23:41  5314828ce328
2026-08-26 12:32  e839b90839a5   <- currently pinned everywhere

This should be a no-op, and that is the claim under test

I pulled both contexts and diffed them:

file old vs new
cluster-context-public.yml identical
adapter-compat.yaml identical
context-manifest.yml sourceSha: 22b9d3327ee477c1
MANIFEST.sha256 the hash of the above

So the only substantive change is the provenance field. Nothing a consumer renders should move.

The node-contract reconciliation that prompted this (nix-config#22, homelab-inventory#17) landed in the internal context, not the public one — which is why the public payload is unchanged.

Why one repo and not sixteen

The estate's own replay procedure says to always run a known-good consumer as a control, because when the deploy-artifact harness was first exercised it reported both configurations as failing, and the control is what showed the harness was wrong rather than the manifests.

auth-ui is that control here: simple, fast CI, and currently healthy. Read the deploy-preview render, not the green tick — if the rendered manifests are identical to the previous run, the bump is safe and the remaining 14 pin sites can follow. If they are not, the assumption above is wrong and I would rather find out on one repo.

Not included

Two further matches for the old digest live in services/auth-api/.claude/worktrees/generic-500/ — stray local worktree state inside that submodule, not a real consumer. Reported on #53 rather than touched.

🤖 Generated with Claude Code

Control bump for JorisJonkers-dev/workspace#53. The published context has
moved on three times since e839b908 while every consumer stayed pinned to
it.

Comparing the two contexts by pulling both: cluster-context-public.yml and
adapter-compat.yaml are byte-identical. The only substantive difference is
the sourceSha provenance field, 22b9d332 -> 7ee477c1.

So this should render identically. That is the point of doing one repo
first: the estate's replay procedure says always run a known-good consumer
as a control, because the first harness reported both configurations as
failing and only the control showed the harness was wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@ExtraToast ExtraToast added type: chore Maintenance work without intended behavior change. component: deploy Deployment pipeline, manifests, or release rollout. labels Aug 27, 2026
@ExtraToast ExtraToast self-assigned this Aug 27, 2026
@github-actions

Copy link
Copy Markdown

Deploy Preview — auth-ui

Environments: production
Context ref: ghcr.io/jorisjonkers-dev/cluster-deploy-context-public@sha256:95dc39fc695694c8fb4b0c538d7fe13038d407c7302c3725c98f0496c6a83499
Workloads: 1 | Routes: 1 | Gatus endpoints: 1

Image refs

  • auth-ui: ghcr.io/jorisjonkers-dev/auth-ui@sha256:0000000000000000000000000000000000000000000000000000000000000000

SC-11 Readiness Scorecard

Check Status Detail
schema_pinned pass
context_pinned pass
no_latest_images pass
health_declared pass
route_owner_authmode_declared pass
rollback_retention_acknowledged pass
no_raw_secrets pass
stateful_policy_declared not_applicable deployment declares no stateful workloads
raw_manifests_guarded not_applicable no workload enables rawManifests
npm_signatures_verified not_applicable provenance is only evaluated when publishing an artifact

pass = ready · fail = blocks deployment · not_applicable = check does not apply

➖ 3 check(s) not applicable: stateful_policy_declared, raw_manifests_guarded, npm_signatures_verified


Updated by deploy-check on push to this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

component: deploy Deployment pipeline, manifests, or release rollout. type: chore Maintenance work without intended behavior change.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant