semantics.md: GitHub App REGISTRATION is API-doable at 4.1.2 — say so (#74 leftover) #84

New issue

Closed

opened 2026-07-16 15:57:32 +00:00 by dan-claude-bot · 0 comments

dan-claude-bot commented

2026-07-16 15:57:32 +00:00

(Migrated from github.com)

Summary

The last unticked box from #74, left behind when #82 landed. #82 fixed the association claim (which App clones a repo — now resolved via source_id ↔ GET /github-apps); it did not touch what semantics.md says about registration.

Per the #72 audit, POST /github-apps + POST /security/keys exist at v4.1.2 (routes/api.php:131-136). They register an already-created App — you supply app_id / installation_id / the secrets / the private key. What stays manual is the GitHub-side App Manifest flow (creating the App on GitHub in the first place), which is already tracked in #7/#5, and #7's manifest-flow idea remains the real fix.

So the honest split — currently unstated — is:

create the App on GitHub → manual (the Manifest flow; #7)
register it with Coolify → API-doable at 4.1.2
the private key value itself → inherently manual in DR (a credential, not state — CANNOT_RESTORE already says this and stays correct)

What to do

Note in semantics.md's github_apps section that registration of an already-created App is API-doable at 4.1.2, and name the two routes
Draw the create-vs-register-vs-credential line above explicitly, so the DR story isn't read as "all of it is manual"
Cross-reference #7/#5 as the place the remaining manual half is tracked

While in there — known upstream bugs worth recording next to it

From the #72 audit, both relevant if cast ever drives these routes:

coollabsio/coolify#10936 — PATCH /github-apps/{id} rejects a CUID2 private_key_uuid (a contributor has a draft PR)
coollabsio/coolify#5467 — create times out on an instance with many repos

And on next (v4.2, tracked in #77): api_url becomes optional (derived from html_url), and the secrets become readable with a read:sensitive token — which is the same token-abilities change #77 already tracks for custom_labels/compose reads.

Docs-only; no behavior change. Small enough to ride along with any other semantics.md touch.

## Summary The last unticked box from #74, left behind when #82 landed. #82 fixed the *association* claim (which App clones a repo — now resolved via `source_id` ↔ `GET /github-apps`); it did **not** touch what `semantics.md` says about **registration**. Per the #72 audit, `POST /github-apps` + `POST /security/keys` **exist at v4.1.2** (`routes/api.php:131-136`). They register an **already-created** App — you supply `app_id` / `installation_id` / the secrets / the private key. What stays manual is the **GitHub-side App Manifest flow** (creating the App on GitHub in the first place), which is already tracked in #7/#5, and #7's manifest-flow idea remains the real fix. So the honest split — currently unstated — is: - **create the App on GitHub** → manual (the Manifest flow; #7) - **register it with Coolify** → API-doable at 4.1.2 - **the private key value itself** → inherently manual in DR (a credential, not state — `CANNOT_RESTORE` already says this and stays correct) ## What to do - [ ] Note in `semantics.md`'s `github_apps` section that registration of an already-created App is API-doable at 4.1.2, and name the two routes - [ ] Draw the create-vs-register-vs-credential line above explicitly, so the DR story isn't read as "all of it is manual" - [ ] Cross-reference #7/#5 as the place the remaining manual half is tracked ## While in there — known upstream bugs worth recording next to it From the #72 audit, both relevant if cast ever drives these routes: - coollabsio/coolify#10936 — `PATCH /github-apps/{id}` rejects a CUID2 `private_key_uuid` (a contributor has a draft PR) - coollabsio/coolify#5467 — create times out on an instance with many repos And on `next` (v4.2, tracked in #77): `api_url` becomes optional (derived from `html_url`), and the secrets become readable with a `read:sensitive` token — which is the same token-abilities change #77 already tracks for `custom_labels`/compose reads. Docs-only; no behavior change. Small enough to ride along with any other `semantics.md` touch.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/cast#84

No description provided.