Skip to content

docs(github): explain where a push gets its secrets, and release ownership - #23

Merged
jona62 merged 3 commits into
mainfrom
docs/github-secrets
Sep 30, 2026
Merged

jona62 merged 3 commits into
mainfrom
docs/github-secrets

Conversation

@jona62

@jona62 jona62 commented Sep 29, 2026

Copy link
Copy Markdown
Contributor

A push to a GitHub connection deploys in Rigbox. It resolves secrets: from the connection's encrypted runtime secrets, never from .env, and the docs didn't say so. Two problems followed:

  • values that worked locally were silently missing on pushes;
  • a refused rig deploy ("belongs to another active deployment") left users guessing.

These are the docs for jona62/rig-mvp#484 and for the secrets handoff in rigbox-dev/cli#201.

What changes

  • guides/github.mdx gains a Runtime secrets section. It covers:
    • what a push reads, and how name, from and optional resolve there;
    • what happens when a required or an optional secret is missing;
    • setting values in the console or with rig deploy, and adding a new secret;
    • checking which declared secrets have a value, with rig ci status.
  • configure/secrets.mdx gains a "Where values come from" table for each way of deploying.
  • deploy/release-ownership.mdx is a new page. It covers:
    • the three kinds of owner: a local project, a GitHub connection and an Actions binding;
    • who can take an app over from each;
    • what the refusal says, and what rig deploy then does with its secrets;
    • how to move apps to a GitHub connection and back.
    • The page is linked from the GitHub guide, the secrets page, multi-app, and deployment troubleshooting, and it is in the navigation.
  • The docs say which paths require a secret to be declared first. rig deploy and the API refuse names that the connected branch doesn't declare. The console stores whatever it is given.

Before merging

🤖 Generated with Claude Code

The GitHub guide never mentioned secrets, and the secrets page only said
to run rig deploy locally. A push deploys in Rigbox and resolves
`secrets:` from the connection's encrypted runtime secrets - never from
.env - so values that work locally were silently missing on pushes.

Add a Runtime secrets section to the GitHub guide: what a push reads and
how `name`/`from`/`optional` resolve there, what happens to a missing
required or optional secret, setting values in the console or with
`rig deploy`, adding a new secret, and checking which declared secrets
have a value with `rig ci status`. The secrets page gains a table of
where values come from for each way of deploying, and the GitHub
troubleshooting page points at both.
Nothing explained which deployment owns an app, what "belongs to another
active deployment" means, or how an app moves between rig deploy and a
GitHub connection - so a refused deploy left users guessing.

Add a Release ownership page: the three kinds of owner (a local project,
a GitHub connection, an Actions binding), who can take an app over from
each, what the refusal says - including the new message naming the
GitHub connection and what rig deploy then does with its secrets - and
the steps to move apps to a GitHub connection and back. Link it from the
GitHub guide, the secrets page, multi-app ownership and deployment
troubleshooting.
Only rig deploy (and the API) refuses names the connected branch does not
declare; the console stores what it is given. Say so, instead of
implying every path needs the declaration pushed first.
@jona62
jona62 merged commit 7946a0c into main Sep 30, 2026
2 checks passed
@jona62
jona62 deleted the docs/github-secrets branch September 30, 2026 01:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant