heavy-duty/cast
7
0
Fork 0
Code Issues 4 Pull requests Projects Releases 3 Packages Wiki Activity Actions

docs(semantics): GitHub App registration is API-doable at 4.1.2 (#84)

Browse source 
The DR table's private-key row read as if the whole GitHub App setup
were manual. Draw the actual split next to it: creating the App on
GitHub is manual (the Manifest flow, tracked in #7/#5), registering an
already-created App with Coolify is API-doable at 4.1.2 (POST
/security/keys + POST /github-apps, routes/api.php:131-136), and only
the private key value itself is inherently manual. Records the two
upstream bugs on these routes (coollabsio/coolify#10936, #5467) and the
v4.2 shape changes #77 tracks.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
claude-hdb 2026-07-16 18:18:14 +00:00
parent 6e8ec34398
commit f25ae8ed30
1 changed files with 27 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
docs/semantics.md
View file

@ -1092,6 +1092,33 @@ The last two are not in the state repo — correctly, it holds no live credentia
— and cannot be regenerated from it. A DR runbook that does not say so is not a — and cannot be regenerated from it. A DR runbook that does not say so is not a
runbook. runbook.
**The GitHub App ❌ row is narrower than it reads — the manual part is the
credential, not the registration (#84).** Three acts hide under "set up the
GitHub App again", and only the first and last lack an API:
- **Creating the App on GitHub** — manual. The GitHub-side App Manifest flow
(name, webhook URL, permissions, the initial private key) has no Coolify
route driving it; automating it is tracked in #7 (and #5), and #7's
manifest-flow idea remains the real fix.
- **Registering an already-created App with Coolify** — **API-doable at
4.1.2**. `POST /security/keys` stores the private key and `POST
/github-apps` registers the App against it — you supply the `app_id`,
`installation_id` and the secrets (`routes/api.php:131-136`, v4.1.2). A DR
rebuild re-registers the App without a UI visit, provided a human holds the
values.
- **The private key *value*** — inherently manual: a credential, not state,
which is exactly what the table's ❌ row says. That row stays correct.
So the DR story reads *"re-mint the credentials by hand, feed them to the
API"*, never *"recreate all of it in the UI"*. Two upstream bugs to know
before cast ever drives these routes: `PATCH /github-apps/{id}` rejects a
CUID2 `private_key_uuid` (coollabsio/coolify#10936 — a contributor has a
draft PR), and the create can time out against an instance with many repos
(coollabsio/coolify#5467). On `next` (v4.2 — tracked in #77) the shape
shifts: `api_url` becomes optional (derived from `html_url`) and the secrets
become readable with a `read:sensitive` token — the same token-abilities
change #77 already tracks.
**What the box cannot tell you, and cast therefore does not invent:** the **What the box cannot tell you, and cast therefore does not invent:** the
`<org>/<repo>` slug comes from an application's git remote (the only place a live `<org>/<repo>` slug comes from an application's git remote (the only place a live
box knows it), so a project with **no application** — a lone service — has no repo box knows it), so a project with **no application** — a lone service — has no repo