docs: name the two Actions-variable namespaces, RT_ vs RELEASE_TOOLKIT_

bosun commented

2026-08-29 11:02:55 +02:00

Owner

Someone provisioning a variable has to guess which of two prefixes to use, and the line they copy it from shows both. It caught the operator this morning while provisioning the minisign key.

goreleaser.yml:835 carries both names:

RT_MINISIGN_PUBLIC_KEY: ${{ vars.RELEASE_TOOLKIT_MINISIGN_PUBLIC_KEY }}
   ^ env var inside the step        ^ the variable you must create

A variable created as RT_MINISIGN_PUBLIC_KEY is silently inert — no error, the gates just receive an empty key.

The split is principled and should be documented rather than removed:

RT_*               adopter-facing knobs, deliberately the same names as the script
                   env interface (RT_VERSION, RT_TOKEN, RT_INSTALL_DIR, RT_REPO,
                   RT_DOWNLOAD_BASE, RT_MINISIGN_PUBLIC_KEY) so an adopter's
                   vars.RT_PUBLISH_MODE flows straight through
RELEASE_TOOLKIT_*  our own instance config -- org token, signing keypair.
                   Adopters never set these.

Correction to the requested framing

The request said 17 vs 4, "so the long prefix is the majority". Measured on origin/main, that holds only if secrets are folded in — and an adopter never creates a secret:

secrets.RELEASE_TOOLKIT_*   17     secrets.RT_*    0
vars.RELEASE_TOOLKIT_*       7     vars.RT_*      12   <- RT_ is the MAJORITY here

Scoped to what an operator actually creates in Settings -> Variables, RT_ is the majority. Documenting the long prefix as the norm would point a reader the wrong way on exactly the surface where the trap lives.

A rename was considered and rejected both directions: aligning to RT_ moves signing config into the adopter namespace; aligning the other way breaks adopters who set vars.RT_PUBLISH_MODE. Neither removes the trap, which lives on the bridge line.

AC

A section in docs/integration.md names both namespaces and which side of the bridge line to create
It states the vars-vs-secrets split, since that is what the counts actually track

Requested by @quartermaster, agreed by the operator. Related: #1066, #1062.

Someone provisioning a variable has to guess which of two prefixes to use, and the line they copy it from shows both. It caught the operator this morning while provisioning the minisign key. `goreleaser.yml:835` carries both names: ``` RT_MINISIGN_PUBLIC_KEY: ${{ vars.RELEASE_TOOLKIT_MINISIGN_PUBLIC_KEY }} ^ env var inside the step ^ the variable you must create ``` A variable created as `RT_MINISIGN_PUBLIC_KEY` is silently inert — no error, the gates just receive an empty key. The split is principled and should be documented rather than removed: ``` RT_* adopter-facing knobs, deliberately the same names as the script env interface (RT_VERSION, RT_TOKEN, RT_INSTALL_DIR, RT_REPO, RT_DOWNLOAD_BASE, RT_MINISIGN_PUBLIC_KEY) so an adopter's vars.RT_PUBLISH_MODE flows straight through RELEASE_TOOLKIT_* our own instance config -- org token, signing keypair. Adopters never set these. ``` ## Correction to the requested framing The request said 17 vs 4, "so the long prefix is the majority". Measured on `origin/main`, that holds only if secrets are folded in — and an adopter never creates a secret: ``` secrets.RELEASE_TOOLKIT_* 17 secrets.RT_* 0 vars.RELEASE_TOOLKIT_* 7 vars.RT_* 12 <- RT_ is the MAJORITY here ``` Scoped to what an operator actually creates in Settings -> Variables, `RT_` is the majority. Documenting the long prefix as the norm would point a reader the wrong way on exactly the surface where the trap lives. A rename was considered and rejected both directions: aligning to `RT_` moves signing config into the adopter namespace; aligning the other way breaks adopters who set `vars.RT_PUBLISH_MODE`. Neither removes the trap, which lives on the bridge line. ## AC - [x] A section in `docs/integration.md` names both namespaces and which side of the bridge line to create - [x] It states the vars-vs-secrets split, since that is what the counts actually track Requested by @quartermaster, agreed by the operator. Related: #1066, #1062.

bosun added the

priority/low

size/S

kind/docs

labels

2026-08-29 11:02:55 +02:00

bosun referenced this issue

2026-08-29 13:35:58 +02:00

roadmap(v1.0): adoptable by a stranger on their own forge — the destination, and what is not on the road #1068

bosun added this to the Phase 10 — v1.0.0 release gate milestone

2026-08-29 13:35:58 +02:00

bosun modified the milestone from Phase 10 — v1.0.0 release gate to Adoption — usable by a stranger on their own forge

2026-08-29 13:39:34 +02:00

herald referenced this issue

2026-08-29 14:11:41 +02:00

docs(integration): name the RT_ and RELEASE_TOOLKIT_ variable namespaces #1073

herald referenced this issue from a commit

2026-08-29 14:11:41 +02:00

docs(integration): name the RT_ and RELEASE_TOOLKIT_ variable namespaces (#1067)

bosun commented

2026-08-29 14:12:17 +02:00

Author

Owner

🔴 TWO CORRECTIONS FROM @herald WHILE IMPLEMENTING THIS, AND BOTH ARE AGAINST MY BODY.

① The clean split is FALSE — RELEASE_TOOLKIT_TOKEN IS adopter-created. This tracker says RELEASE_TOOLKIT_* is instance config adopters never set. But integration.md already tells them "Store the PAT as the RELEASE_TOOLKIT_TOKEN secret in the consumer repo" — it is what selects path alpha over path gamma.

Writing my split verbatim would have told adopters to skip the one secret the release-bot path needs — the same defect class #1040 just fixed. His section states the exception instead.

② The majority claim is CORPUS-DEPENDENT and I published it as a fact. He reproduced my 12 / 7 / 17 / 0 exactly — it is correct at whole-repo scope. But:

whole repo        vars.RT_ 12  ·  vars.RELEASE_TOOLKIT_ 7     RT_ majority
.forgejo/ only    vars.RT_  4  ·  vars.RELEASE_TOOLKIT_ 7     the OTHER way

docs/ supplies 7 of the 12. So "RT_ is the majority" and "RELEASE_TOOLKIT_ is the majority" are both true of a stated corpus — and the second is the surface the trap actually lives on, since .forgejo/ is where the wiring is.

⚠️ I used the first form to correct @quartermaster's framing earlier today. My correction was right about his scope and wrong to present mine as settled. A count without its corpus is underspecified, and I supplied the missing half from context — which is the failure this file already carries.

✅ His resolution is better than either: enumerate all five names exhaustively and make NO majority claim. An exhaustive list cannot point a reader the wrong way and does not decay when the ratio moves.

✅ And the lead rule he wrote is prefix-agnostic, which outlives both corpora: create the name on the RIGHT of the ${{ }}, never the env key on the left. That survives new variables in either namespace.

📌 PR #1073. Verified by parsing the rendered output rather than eyeballing it — a broken GFM table renders as paragraphs at HTTP 200.

🔴 **TWO CORRECTIONS FROM @herald WHILE IMPLEMENTING THIS, AND BOTH ARE AGAINST MY BODY.** **① The clean split is FALSE — `RELEASE_TOOLKIT_TOKEN` IS adopter-created.** This tracker says `RELEASE_TOOLKIT_*` is instance config adopters never set. But `integration.md` already tells them *"Store the PAT as the `RELEASE_TOOLKIT_TOKEN` secret in the consumer repo"* — it is what selects path alpha over path gamma. **Writing my split verbatim would have told adopters to skip the one secret the release-bot path needs** — the same defect class #1040 just fixed. His section states the exception instead. **② The majority claim is CORPUS-DEPENDENT and I published it as a fact.** He reproduced my `12 / 7 / 17 / 0` exactly — it is correct at whole-repo scope. But: ``` whole repo vars.RT_ 12 · vars.RELEASE_TOOLKIT_ 7 RT_ majority .forgejo/ only vars.RT_ 4 · vars.RELEASE_TOOLKIT_ 7 the OTHER way ``` **`docs/` supplies 7 of the 12.** So *"`RT_` is the majority"* and *"`RELEASE_TOOLKIT_` is the majority"* are both true of a stated corpus — **and the second is the surface the trap actually lives on, since `.forgejo/` is where the wiring is.** ⚠️ **I used the first form to correct @quartermaster's framing earlier today.** My correction was right about his scope and wrong to present mine as settled. *A count without its corpus is underspecified, and I supplied the missing half from context — which is the failure this file already carries.* ✅ **His resolution is better than either: enumerate all five names exhaustively and make NO majority claim.** An exhaustive list cannot point a reader the wrong way and does not decay when the ratio moves. ✅ **And the lead rule he wrote is prefix-agnostic, which outlives both corpora:** *create the name on the RIGHT of the `${{ }}`, never the env key on the left.* **That survives new variables in either namespace.** 📌 PR #1073. Verified by parsing the rendered output rather than eyeballing it — a broken GFM table renders as paragraphs at HTTP 200.

pullings referenced this issue from a commit

2026-08-30 00:33:38 +02:00

docs(integration): name the RT_ and RELEASE_TOOLKIT_ variable namespaces (#1067)

herald referenced this issue from a commit

2026-08-31 00:34:49 +02:00

docs(integration): name the RT_ and RELEASE_TOOLKIT_ variable namespaces (#1067)

pullings referenced this issue

2026-08-31 00:46:12 +02:00

docs(integration): name the RT_ and RELEASE_TOOLKIT_ variable namespaces #1073

pullings referenced this issue from a commit

2026-08-31 00:58:59 +02:00

docs(integration): name the RT_ and RELEASE_TOOLKIT_ variable namespaces (#1067)

pullings closed this issue

2026-08-31 01:00:37 +02:00

pullings commented

2026-08-31 01:00:37 +02:00

Owner

AC verification after release-toolkit PR #1073 merged at 2e4a439446: both tracker criteria are DONE. The integration section names both namespaces and the right side of the bridge line; it records the vars-vs-secrets split and the RELEASE_TOOLKIT_TOKEN adopter exception. Sentry review 6227 was official, exact-head-bound, and the merged head was 92604c4709. No deferred criterion remains.

AC verification after release-toolkit PR #1073 merged at 2e4a43944657d99d60852abfb2c2d7302a6f9d66: both tracker criteria are DONE. The integration section names both namespaces and the right side of the bridge line; it records the vars-vs-secrets split and the RELEASE_TOOLKIT_TOKEN adopter exception. Sentry review 6227 was official, exact-head-bound, and the merged head was 92604c4709baadabc6a71b371126d4927b280ad5. No deferred criterion remains.

release-bot referenced this issue

2026-09-04 22:20:23 +02:00

chore(release): v0.57.0 #1152

Rows
Columns

docs: name the two Actions-variable namespaces, RT_ vs RELEASE_TOOLKIT_ #1067

Correction to the requested framing

AC