Repository navigation
Releases: underwhelmingperformance/cupboard
Release list
v0.0.44
Substitute from the release cache
Cupboard publishes every versioned release to one Nix binary cache.
Configure it once in nix.conf to fetch releases instead of building:
extra-substituters = https://cupboard.supply/t/cupboard/cache/releases
extra-trusted-public-keys = cupboard-1:tiaTSFvY6LqLUwbjsNcig64LnxZ+T5EQgW5Cr4XjXqU=
Upgrade guidance
No additional upgrade steps are required for this release.
What's Changed
- chore(deps): update orpc monorepo to v1.15.5 by @moverofthings[bot] in #481
- fix(publication): avoid repeated missing dependency checks by @iainlane in #483
Full Changelog: v0.0.43...v0.0.44
v0.0.43
Substitute from the release cache
Cupboard publishes every versioned release to one Nix binary cache.
Configure it once in nix.conf to fetch releases instead of building:
extra-substituters = https://cupboard.supply/t/cupboard/cache/releases
extra-trusted-public-keys = cupboard-1:tiaTSFvY6LqLUwbjsNcig64LnxZ+T5EQgW5Cr4XjXqU=
Upgrade guidance
Publication reuse now follows the trust direction
Upgrade the server to the access-checked reuse release before updating callers
of the flake publication workflow.
The pull-request-and-branch preset now uses the tenant's default cache as the
PR reference source. The preset adds no PR reference source on branch runs by
default. Setup no longer creates the pull-requests-<repository-id> prefix
view, and the preset ignores reuse-view. Existing views remain available to
explicit consumers; remove an unused view only after checking those consumers.
Caller-defined read-caches, nix-config and remote builder substituters still
apply. Remove PR-view URLs from those settings if branch runs must stop reading
PR outputs.
Run cupboard github setup again to grant a PR access to a private default
cache. Read grants are required for publication by reference when the source
cache is private.
To allow trusted contributors' PR outputs on branch runs, select
cupboard-flake-publish-trusted.yml in the caller, grant pull-requests: read,
and run setup with --trusted-contributor-reuse. The wrapper reads only the
unique merged PR cache associated with the branch push commit. Direct pushes,
ambiguous matches and failed lookups build instead. A PR controls its own
nix-config and builders, so enable this mode only for trusted contributors.
Use the flake publication guide for the caller and trust-rule
requirements. cupboard github check --fix can repair tenant read grants. The
command reports the required caller edits without changing workflow files.
What's Changed
- fix(publication): promote cached tenant build dependencies by @iainlane in #474
- feat(publication): explain publication decisions and outcomes by @iainlane in #476
- perf(ci): reduce evaluation work during publication planning by @iainlane in #477
- chore(deps): update dependency @aws-sdk/client-s3 to v3.1147.0 by @moverofthings[bot] in #475
- feat(ci): make publication reuse an explicit trust choice by @iainlane in #478
- test: assert workflow contracts and process lifecycle events by @iainlane in #479
Full Changelog: v0.0.42...v0.0.43
v0.0.42
Substitute from the release cache
Cupboard publishes every versioned release to one Nix binary cache.
Configure it once in nix.conf to fetch releases instead of building:
extra-substituters = https://cupboard.supply/t/cupboard/cache/releases
extra-trusted-public-keys = cupboard-1:tiaTSFvY6LqLUwbjsNcig64LnxZ+T5EQgW5Cr4XjXqU=
Upgrade guidance
No additional upgrade steps are required for this release.
What's Changed
Full Changelog: v0.0.41...v0.0.42
v0.0.41
Substitute from the release cache
Cupboard publishes every versioned release to one Nix binary cache.
Configure it once in nix.conf to fetch releases instead of building:
extra-substituters = https://cupboard.supply/t/cupboard/cache/releases
extra-trusted-public-keys = cupboard-1:tiaTSFvY6LqLUwbjsNcig64LnxZ+T5EQgW5Cr4XjXqU=
Upgrade guidance
Reuse of stored NARs
A push reuses a NAR that the tenant already stores only if the push can already
read it. A readable reference to the NAR must belong to the destination cache, a
public cache in the tenant, a cache covered by cache:content-read, or a cache
in a reuse view covered by view:content-read. Earlier releases reused a NAR
that any cache in the tenant referred to.
Some pushes that skipped the upload in earlier releases now upload the bytes.
This happens when only private caches that the push token can't read refer to
the NAR. For example, a pull-request job that pushes to a public pull-request
cache now uploads a path that only a private cache has.
Publishing by reference from a private cache or a private reuse view needs the
same grant on the push token when the source differs from the destination.
cupboard push now requests cache:content-read or view:content-read for
each private source in the same tenant, whether the source is given with
--reference-source or in a reference manifest. A token request is all or
nothing, so if the trust rule does not permit the grant, the push gets no token
and reports the refused request with its private sources.
A tenant whose flake publish workflow reuses paths from a private reuse view
must permit view:content-read for that view in the trust rule of its branch
runs. This applies whether the workflow reads the view through OIDC or with a
static read credential. cupboard github check reports the missing grant, and
its guided repair adds it.
cupboard still stores each NAR once.
Use cupboard check --shared-access <tenant-url> to review NARs that public and
private caches both reference. The report requires check:run and changes no
publications.
Control database split
This upgrade moves control keys, trust rules, operator sessions, consumed
subject nonces, the administrator record and maintenance reports from
CUPBOARD_DB to CONTROL_DB. Only the control Worker receives the new binding.
The shared store and tenant registry remain in CUPBOARD_DB.
Use cupboard deploy or cupboard init. The command prepares both schemas,
uploads compatible Workers, freezes legacy control mutations, copies the rows in
bounded pages, checks complete source and target contents, and validates wrapped
signing keys with the control Worker's existing wrapping secret. It then
publishes target readiness and removes the old control tables. Preserve
CONTROL_KEY_WRAP_SECRET; replacing that secret prevents key validation.
The migration assumes that the legacy database has not been compromised. Key
validation checks the wrapped private material, matching public keys and unique
key IDs. The database contains no authenticated writer history for trust rules,
administrator records or key metadata. If compromise is suspected, establish
independently reviewed authority data before upgrading. The copy cannot identify
a correctly shaped forged authority row.
The cutover is irreversible. Both Workers add an unbound Durable Object class so
Cloudflare refuses dashboard rollback across the release. Before freezing, the
deploy also records the shared control-database-split contract marker so older
cupboard deployment tools refuse the database. See Cloudflare
rollbacks.
While the source is frozen and the target is incomplete, control token issuance
and authority mutations return a temporary failure. Existing tenant cache
traffic continues. Refresh families, spent members, retry envelopes, revoked
sessions, disabled trust rules, retired keys and consumed nonces retain their
stored values.
If the command stops, rerun the same deployment with the same database bindings
and deployment URL. The deploy recognises reciprocal source and target markers
and the irreversible contract marker on an unfinished transition. Cloudflare
deployment credentials permit that forward recovery even if the source cannot
renew an administrator token. Normal administrator authentication is required
once the cutover transition is complete. The command installs a temporary
control-only validation secret for its key check and removes that secret
afterwards.
A mismatched target row or invalid key stops the copy before readiness. Preserve
both databases and correct the reported problem, then resume. Do not clear the
source freeze marker, replace target authority from the stale source after
readiness, or deploy a preceding release. A ready target is authoritative and
can already contain newer revocations and sessions.
What's Changed
- test(scripts): isolate git fixtures from the caller's repository by @iainlane in #464
- fix(server): fail the commit fixture when its passes run out by @iainlane in #465
- fix(server): preserve deferred verdicts and release ignored claims by @iainlane in #470
- fix(cli): exit 75 only for transient GitHub OIDC failures by @iainlane in #469
- fix(server): isolate control authority in a separate database by @iainlane in #471
- fix(publication): require readable authority when reusing stored NARs by @iainlane in #472
Full Changelog: v0.0.40...v0.0.41
v0.0.40
Substitute from the release cache
Cupboard publishes every versioned release to one Nix binary cache.
Configure it once in nix.conf to fetch releases instead of building:
extra-substituters = https://cupboard.supply/t/cupboard/cache/releases
extra-trusted-public-keys = cupboard-1:tiaTSFvY6LqLUwbjsNcig64LnxZ+T5EQgW5Cr4XjXqU=
Upgrade guidance
Bound subject tokens
The deployment refuses every exchange of an external subject token that isn't
bound to the server that receives it. This applies to POST /token and
POST /signup at the deployment URL, and to token exchanges and read
acquisitions at POST /t/<tenant>/token. A refused exchange returns status 400
with the error invalid_grant and the problem subject-token-unbound.
A token is bound in one of two ways:
- Its audience is the URL of the server that receives it: the tenant URL for a
tenant, and the deployment URL for the control plane. A GitHub Actions job
requests such a token. - Its
nonceclaim commits to that URL. The CLI requests such a token for every
sign-in.
The refusal has these consequences:
- A CLI from an earlier release sends its sign-in tokens without the binding, so
it can't sign in. Upgrade the CLI with the deployment. --headlessno longer uses the device flow. It prints the sign-in URL and
accepts the redirect URL that you paste from a browser on another machine. See
Signing in without a browser.- A CI job can't exchange a token whose audience isn't the URL of the server
that it sends the token to. That includes the token for a tenant trust rule
with a custom audience. It also includes a token for the control plane that a
job requests for another hostname of the deployment, such as its workers.dev
hostname when the deployment URL is a custom domain. Set the rule's audience,
and the job'saudienceinput or--audienceoption, to the tenant URL, or
to the deployment URL for a control trust rule.
Before you upgrade, find the trust rules that stop working. A rule stops working
when both of these are true:
- Its audience isn't the URL of the server that receives the token: the tenant
URL for a tenant trust rule, or the deployment URL for a control trust rule. - A CI job, or another caller that doesn't sign in through the CLI, presents
tokens for the rule.
A rule for people who sign in with the CLI keeps working whatever its audience,
because the CLI binds every sign-in token with its nonce.
To find these rules:
- Run
cupboard github checkfor each repository that publishes to a tenant. It
warns about each GitHub Actions trust rule for the repository whose audience
isn't the tenant URL. - List each tenant's trust rules with
cupboard oidc-trust list <tenant URL>,
and the control plane's with
cupboard control-oidc-trust list <deployment URL>. Each rule shows its
audience. Check every rule that CI or another caller without the CLI uses,
including rules for other CI providers, whichcupboard github checkdoesn't
cover.
HTTPS only
The control Worker refuses every request that doesn't use HTTPS. It returns
status 403 with the problem insecure-transport, and doesn't process the
request. HTTPS responses other than WebSocket upgrades include the header
Strict-Transport-Security: max-age=31536000, so a browser uses HTTPS for the
host for the next year.
Before you upgrade, check that nothing uses an http:// URL for the deployment:
Nix substituter settings, netrc files, CI configuration and scripts. Change
those URLs to https://. Also check that no tenant was created at an http://
URL. Such a tenant keeps that URL as its issuer, and the deployment no longer
serves that address.
wrangler dev serves plain HTTP. Set CUPBOARD_LOCAL_DEV=1 in
packages/server/.dev.vars to allow plain HTTP requests to a local deployment.
For a custom domain, you can also turn on Always Use HTTPS and HSTS for its
zone. Those settings apply to every host in the zone. See HTTPS for a custom
domain.
What's Changed
- fix: make push diagnostics complete and identify each verification by @iainlane in #457
- perf(cli): faster NAR serialisation and Nix-style zstd frames by @iainlane in #458
- perf(server): read staged NARs ahead with ranged R2 gets by @iainlane in #463
- fix(server): stop concurrent verdicts stranding a pending upload by @iainlane in #460
- test(scripts): disable auto maintenance in temporary repositories by @iainlane in #461
- fix(test): keep directory watches out of cancelled daemon waits by @iainlane in #462
- feat: bind subject tokens to their targets and harden authentication by @iainlane in #459
- perf(cli): stream multipart NAR uploads during compression by @iainlane in #466
- perf(server): fuse NAR verification and promotion by @iainlane in #467
- feat(cli): declare compressed blobs for fused promotion by @iainlane in #468
Full Changelog: v0.0.39...v0.0.40
v0.0.39
Substitute from the release cache
Cupboard publishes every versioned release to one Nix binary cache.
Configure it once in nix.conf to fetch releases instead of building:
extra-substituters = https://cupboard.supply/t/cupboard/cache/releases
extra-trusted-public-keys = cupboard-1:tiaTSFvY6LqLUwbjsNcig64LnxZ+T5EQgW5Cr4XjXqU=
Upgrade guidance
No additional upgrade steps are required for this release.
What's Changed
- chore(deps): update aws-sdk-js-v3 monorepo to v3.1146.0 by @moverofthings[bot] in #452
- chore(deps): update dependency msw to v3 by @moverofthings[bot] in #439
- fix(deps): update all non-major dependencies by @moverofthings[bot] in #433
- fix(server): verify staged NARs in 1 MiB reads by @iainlane in #455
- fix: keep uploads alive until their commits arrive by @iainlane in #456
Full Changelog: v0.0.38...v0.0.39
v0.0.38
Substitute from the release cache
Cupboard publishes every versioned release to one Nix binary cache.
Configure it once in nix.conf to fetch releases instead of building:
extra-substituters = https://cupboard.supply/t/cupboard/cache/releases
extra-trusted-public-keys = cupboard-1:tiaTSFvY6LqLUwbjsNcig64LnxZ+T5EQgW5Cr4XjXqU=
Upgrade guidance
No additional upgrade steps are required for this release.
What's Changed
Full Changelog: v0.0.37...v0.0.38
v0.0.37
Substitute from the release cache
Cupboard publishes every versioned release to one Nix binary cache.
Configure it once in nix.conf to fetch releases instead of building:
extra-substituters = https://cupboard.supply/t/cupboard/cache/releases
extra-trusted-public-keys = cupboard-1:tiaTSFvY6LqLUwbjsNcig64LnxZ+T5EQgW5Cr4XjXqU=
Upgrade guidance
Tenant migration readiness
init now checks the tenant schema after every upload, even when the tenants
already completed the previous release's data work. This upgrade adds schema
progress to the control database and verifies every active or suspended tenant
before reporting readiness. Existing tenants initially appear as waiting to
start until their objects run the verification.
init waits for pending tenants and shows progress. Press Ctrl-C to quit the
wait; the queued wakes and tenant alarms continue on the server. Use
cupboard deployment status <deployment URL> to check progress and
cupboard deployment resume <deployment URL> to wait again. The status command
shows readiness and tenant progress by default. Pass --debug for schema
transition states and migration identifiers.
Attestation discovery
The legacy POST /api/v1/attested-paths endpoint is removed from default and
named caches. Use POST /api/v1/attestation-info for batched discovery of
stored attestation metadata. The CLI uses this interface for
cupboard attest status and the publication coverage report.
Clients can use bounded individual attestation-list reads when the server does
not advertise attestation-info-v1. Authentication and storage failures remain
errors and do not permit fallback. Discovery does not verify attestation
signatures; use cupboard attest verify for verification.
Simple workflow PR caches
The simple cupboard-publish.yml workflow accepts manage-pr-cache: true with
an explicit cache input. Add closed and reopened to the caller's
pull_request event types, and grant cache:create, cache:close and
cache:reopen for the selected cache. Setup acquires read authority before
creating a missing cache. Existing publication grants and cache:create already
imply scoped cache:read, which permits the absence response. Private content
requires a cache:content-read grant without a root selector. Closed runs skip
builds and publication, including merged pull requests. Existing calls leave
this input disabled.
Newly created PR caches inherit the tenant's default creation grace. A close
expires their roots at the close time, while reads and reuse remain available
through grace. Reopening restores writes. See Managing PR
caches.
Path deletion and rollback
Complete cupboard deploy before deleting a store path. The deployment uploads
both Workers, verifies that both serve the new build, then activates path read
revocation through 0036_path_read_authority_contract.sql. Changes to shared
NAR and attestation references return a retryable error until the contract step
completes. Resume an interrupted deployment with the same CLI release and
source. If the admin preflight returns an HTTP error, read the Worker logs with
wrangler tail cupboard --format json, fix the cause and re-run cupboard init
with that release and source.
Both Workers introduce the unbound PathReadAuthorityRollbackGuard Durable
Object class. Cloudflare blocks version rollback across this class lifecycle
change. After the contract step starts, preceding CLIs also refuse to deploy
against the recorded transition. Recover by completing this deployment. The
contract replaces the preceding reference tables with read-only authority views
and replaces the preceding cache-admission table with an empty view. A preceding
request that has not yet read cache authority is refused before it can serve an
R2 object. A request admitted before contraction may finish under the existing
streaming contract.
After contraction, both Workers must use this release or a compatible successor
that reads the physical storage tables. Preceding Workers cannot admit cache
reads or change cache lifecycle rows. Current public and private cache access is
unchanged. Lifecycle projection can finish before contraction; lifecycle writes
refuse retryably while the contract step runs.
Grace defaults for new caches
Deploy the server before using cupboard cache set-default-grace,
clear-default-grace or defaults. Local migration
0070_cache_creation_defaults adds a tenant-local creation setting. The initial
setting is no grace, and existing caches keep their current settings.
New caches inherit the setting when creation does not specify grace. This also
applies to implicit creation by publication, root writes or attestation writes.
cache create --grace overrides the setting for that cache. Older clients that
explicitly send no grace continue to override the creation default; adopt this
release's CLI and actions when the default should apply to those callers.
Complete any outstanding legacy retention import before creating caches or
changing creation defaults. Creation waits for that import even when the
requested grace is omitted or explicitly disabled, so the import cannot
overwrite a new cache's selected settings.
Delegated tenant administration needs cache:defaults-read to inspect the
setting and cache:defaults-update to change it. Individual cache grants do not
permit either operation. Cache creation defaults describes the commands.
PR cache closure
Deploy this release's server before adopting its CLI or reusable publishing
workflows. Closing a PR now closes its cache on both merged and unmerged close
events. Reads and reuse remain available during the configured grace period; GC
removes expired content and deletes the empty cache after pending work ends.
Reopening explicitly restores write access.
Existing PR trust rules need cache:close and cache:reopen. Merged close runs
also need a separate closure-only rule because GitHub's signed ref changes to
the base branch. The new rule uses a bounded named-cache pattern over the
repository's PR cache family and requires the repository and owner IDs,
event_name=pull_request, a base-branch ref and the workflow pin. It does not
grant publication, metadata or content reads, roots or reopening. The new
cache:close operation does not imply cache:read; an exact lifecycle grant
must include cache:read explicitly if its caller also inspects metadata.
Deploy the server before adding this pattern binding.
A cache:delete grant does not permit either operation. After deploying the
server, run cupboard github check with --repo, --fix and
--trust-scope exact to review the grants and close-only rules that the
repository's current workflows require. Matched GitHub rules can receive an
atomic grant extension that preserves their IDs, selectors and existing grants.
The extension refuses a rule that changed after the preview. Confirm the repair,
or use --yes for a reviewed non-interactive run.
For a deliberately selected branch workflow, including Cupboard's @main
dogfood workflow, also pass --allow-branch-workflow. This choice trusts future
edits to that branch's workflow. The merged-close helper accepts the same
explicit choice with an exact @refs/heads/<branch> reference. Preserve the
publication rule's cache family with --cache-template. See PR trust rules.
If the calling workflow explicitly lists pull_request.types, include both
closed and reopened. The closed event starts grace; the reopened event
restores writes before publication. See PR cache lifecycle.
Refresh credentials
Deploy the server before adopting the new CLI or workflow behaviour. Local
migration 0067_refresh_session_authority creates the minimal rotation and
replay tables without copying old session authority. Existing access JWTs remain
valid until their normal expiry. Legacy refresh credentials require a new login;
the CLI can use a saved Cloudflare sign-in when that sign-in remains valid.
New refresh credentials include their verified policy identity, authority
ceiling and absolute expiry. Renewal evaluates current trust policy and does not
depend on an originating rule. The server stores the complete credential's hash,
family and generation metadata, and temporarily an encrypted successor
credential for lost-response recovery. [Session renewal][cupboard-upgrade-183e48b1b4758c102e8e66b9772ffd56755f0e4beba17feed1a9cac86a9c8dc3] explains the grace
window and policy changes.
Old refresh tables temporarily ...
v0.0.36
Substitute from the release cache
Cupboard publishes every versioned release to one Nix binary cache.
Configure it once in nix.conf to fetch releases instead of building:
extra-substituters = https://cupboard.supply/t/cupboard/cache/releases
extra-trusted-public-keys = cupboard-1:tiaTSFvY6LqLUwbjsNcig64LnxZ+T5EQgW5Cr4XjXqU=
Upgrade guidance
Tenant migration readiness
init now checks the tenant schema after every upload, even when the tenants
already completed the previous release's data work. This upgrade adds schema
progress to the control database and verifies every active or suspended tenant
before reporting readiness. Existing tenants initially appear as waiting to
start until their objects run the verification.
init waits for pending tenants and shows progress. Press Ctrl-C to quit the
wait; the queued wakes and tenant alarms continue on the server. Use
cupboard deployment status <deployment URL> to check progress and
cupboard deployment resume <deployment URL> to wait again. The status command
shows readiness and tenant progress by default. Pass --debug for schema
transition states and migration identifiers.
Attestation discovery
The legacy POST /api/v1/attested-paths endpoint is removed from default and
named caches. Use POST /api/v1/attestation-info for batched discovery of
stored attestation metadata. The CLI uses this interface for
cupboard attest status and the publication coverage report.
Clients can use bounded individual attestation-list reads when the server does
not advertise attestation-info-v1. Authentication and storage failures remain
errors and do not permit fallback. Discovery does not verify attestation
signatures; use cupboard attest verify for verification.
Simple workflow PR caches
The simple cupboard-publish.yml workflow accepts manage-pr-cache: true with
an explicit cache input. Add closed and reopened to the caller's
pull_request event types, and grant cache:create, cache:close and
cache:reopen for the selected cache. Setup acquires read authority before
creating a missing cache. Existing publication grants and cache:create already
imply scoped cache:read, which permits the absence response. Private content
requires a cache:content-read grant without a root selector. Closed runs skip
builds and publication, including merged pull requests. Existing calls leave
this input disabled.
Newly created PR caches inherit the tenant's default creation grace. A close
expires their roots at the close time, while reads and reuse remain available
through grace. Reopening restores writes. See Managing PR
caches.
Path deletion and rollback
Complete cupboard deploy before deleting a store path. The deployment uploads
both Workers, verifies that both serve the new build, then activates path read
revocation through 0036_path_read_authority_contract.sql. Changes to shared
NAR and attestation references return a retryable error until the contract step
completes. Resume an interrupted deployment with the same CLI release and
source. If the admin preflight returns an HTTP error, read the Worker logs with
wrangler tail cupboard --format json, fix the cause and re-run cupboard init
with that release and source.
Both Workers introduce the unbound PathReadAuthorityRollbackGuard Durable
Object class. Cloudflare blocks version rollback across this class lifecycle
change. After the contract step starts, preceding CLIs also refuse to deploy
against the recorded transition. Recover by completing this deployment. The
contract replaces the preceding reference tables with read-only authority views
and replaces the preceding cache-admission table with an empty view. A preceding
request that has not yet read cache authority is refused before it can serve an
R2 object. A request admitted before contraction may finish under the existing
streaming contract.
After contraction, both Workers must use this release or a compatible successor
that reads the physical storage tables. Preceding Workers cannot admit cache
reads or change cache lifecycle rows. Current public and private cache access is
unchanged. Lifecycle projection can finish before contraction; lifecycle writes
refuse retryably while the contract step runs.
Grace defaults for new caches
Deploy the server before using cupboard cache set-default-grace,
clear-default-grace or defaults. Local migration
0070_cache_creation_defaults adds a tenant-local creation setting. The initial
setting is no grace, and existing caches keep their current settings.
New caches inherit the setting when creation does not specify grace. This also
applies to implicit creation by publication, root writes or attestation writes.
cache create --grace overrides the setting for that cache. Older clients that
explicitly send no grace continue to override the creation default; adopt this
release's CLI and actions when the default should apply to those callers.
Complete any outstanding legacy retention import before creating caches or
changing creation defaults. Creation waits for that import even when the
requested grace is omitted or explicitly disabled, so the import cannot
overwrite a new cache's selected settings.
Delegated tenant administration needs cache:defaults-read to inspect the
setting and cache:defaults-update to change it. Individual cache grants do not
permit either operation. Cache creation defaults describes the commands.
PR cache closure
Deploy this release's server before adopting its CLI or reusable publishing
workflows. Closing a PR now closes its cache on both merged and unmerged close
events. Reads and reuse remain available during the configured grace period; GC
removes expired content and deletes the empty cache after pending work ends.
Reopening explicitly restores write access.
Existing PR trust rules need cache:close and cache:reopen. Merged close runs
also need a separate closure-only rule because GitHub's signed ref changes to
the base branch. The new rule uses a bounded named-cache pattern over the
repository's PR cache family and requires the repository and owner IDs,
event_name=pull_request, a base-branch ref and the workflow pin. It does not
grant publication, metadata or content reads, roots or reopening. The new
cache:close operation does not imply cache:read; an exact lifecycle grant
must include cache:read explicitly if its caller also inspects metadata.
Deploy the server before adding this pattern binding.
A cache:delete grant does not permit either operation. After deploying the
server, run cupboard github check with --repo, --fix and
--trust-scope exact to review the grants and close-only rules that the
repository's current workflows require. Matched GitHub rules can receive an
atomic grant extension that preserves their IDs, selectors and existing grants.
The extension refuses a rule that changed after the preview. Confirm the repair,
or use --yes for a reviewed non-interactive run.
For a deliberately selected branch workflow, including Cupboard's @main
dogfood workflow, also pass --allow-branch-workflow. This choice trusts future
edits to that branch's workflow. The merged-close helper accepts the same
explicit choice with an exact @refs/heads/<branch> reference. Preserve the
publication rule's cache family with --cache-template. See PR trust rules.
If the calling workflow explicitly lists pull_request.types, include both
closed and reopened. The closed event starts grace; the reopened event
restores writes before publication. See PR cache lifecycle.
Refresh credentials
Deploy the server before adopting the new CLI or workflow behaviour. Local
migration 0067_refresh_session_authority creates the minimal rotation and
replay tables without copying old session authority. Existing access JWTs remain
valid until their normal expiry. Legacy refresh credentials require a new login;
the CLI can use a saved Cloudflare sign-in when that sign-in remains valid.
New refresh credentials include their verified policy identity, authority
ceiling and absolute expiry. Renewal evaluates current trust policy and does not
depend on an originating rule. The server stores the complete credential's hash,
family and generation metadata, and temporarily an encrypted successor
credential for lost-response recovery. [Session renewal][cupboard-upgrade-183e48b1b4758c102e8e66b9772ffd56755f0e4beba17feed1a9cac86a9c8dc3] explains the grace
window and policy changes.
Old refresh tables temporarily ...
v0.0.35
Substitute from the release cache
Cupboard publishes every versioned release to one Nix binary cache.
Configure it once in nix.conf to fetch releases instead of building:
extra-substituters = https://cupboard.supply/t/cupboard/cache/releases
extra-trusted-public-keys = cupboard-1:tiaTSFvY6LqLUwbjsNcig64LnxZ+T5EQgW5Cr4XjXqU=
What's Changed
- chore(deps): update aws-sdk-js-v3 monorepo to v3.1136.0 by @moverofthings[bot] in #386
- fix(ci): resolve cache publish CLI from workflow commit by @iainlane in #390
- chore(deps): update dependency eslint-plugin-unicorn to v76 by @moverofthings[bot] in #387
- fix(ci): pin release cache public key by @iainlane in #388
- fix(cli): recover built provenance from hook outputs by @iainlane in #389
Full Changelog: v0.0.34...v0.0.35