Skip to content

Add the default-off release-recovery publication workflow #717

Description

@devantler

🤖 Generated by the Agentic Engineer

Problem

Once the publisher command exists, operators still need a reviewed, default-off way to run it in the affected repository without rerunning release plugins or widening credentials (#602).

Smallest useful change

Add a default-off reusable recovery workflow that calls the publisher command:

  • It runs only in the affected public repository on its default branch, sharing the normal release concurrency group.
  • It builds the publisher from immutable catalogue code before any credential is issued.
  • It admits the incident with a one-repository read token. It stops as a verified no-op when the publication already exists, before any writer token is minted.
  • Only then does it mint a token with Contents(write) and Actions(read) for that one repository.
  • It keeps a permanent, explicit operator confirmation separate from the temporary rollout flag. Production publication is manual-dispatch only.

Acceptance criteria

  • Default-off and explicit enabled/offline CI calls run without production credentials. Every reusable caller is covered by the required aggregate.
  • Workflow-authority guards cover scoped permissions, immutable source and the order of read token before writer token, with negative controls.
  • Operator documentation is written, reviewed, merged and released.
  • Rollout and removal of the short-lived flag are tracked as separate open work (Complete release-recovery rollout and decide the opt-in lifecycle #603) before the flag ships.

Depends on

The publisher-command child of #602.

Activity

  1. moved this to 📥 Backlog in 🌊 Project Boardon Oct 22, 2026
  2. devantler commented on Oct 22, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    A point to settle in this slice, carried over from the publisher's review (#718).

    The publisher proves write access by reading permissions.push from the repository response with its own credential, and it refuses when that field is absent. The offline controls cannot answer two questions:

    1. Does the scoped App installation token's repository read include that field? If it does not, every run is refused.
    2. Is the field the token's capability, or only the owner's role? For a user-owned fine-grained token, push reflects the user's role, not the token's scope. That is why only the scoped App token should ever be passed.

    The workflow's acceptance should include one native observation of the field under the minted Contents(write) and Actions(read) token. The observation reads only; it publishes nothing.

  3. moved this from 📥 Backlog to 🫴 Ready in 🌊 Project Boardon Oct 22, 2026
  4. moved this from 🫴 Ready to 👀 In Review in 🌊 Project Boardon Oct 22, 2026
  5. added a commit that references this issue on Oct 22, 2026
    ddb835f
  6. moved this from 👀 In Review to ✅ Done in 🌊 Project Boardon Oct 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Fields

    Priority

    None yet

    Start date

    None yet

    Target date

    None yet

    Effort

    None yet

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions