chore: Settle one name for the GlitchTip DSN across the fleet

ahmad commented

2026-09-08 19:46:50 +00:00

Owner

Context

The same GlitchTip DSN is stored under two different secret names across the fleet, and in one repo a single name covers two scopes:

ahmad/expiro — the Forgejo repo secret is VITE_GLITCHTIP_DSN, consumed as a build arg (release.yml:196).
ahmad/larda — the repo secret is GLITCHTIP_DSN. release.yml:196 maps it to the VITE_GLITCHTIP_DSN build arg for the web bundle, and GLITCHTIP_DSN is also the name of the api's runtime value from OpenBao secret/larda (release.yml:344, deploy.yml:154).

Two costs. Someone wiring a third repo has no rule to copy — both existing repos are precedents and they disagree. And in larda the two uses cannot be given different values or rotated separately, because they share a name: the DSN baked into a public bundle and the one the server process holds are the same string by construction rather than by decision.

Found while reviewing infrastructure-vps#428. Filed first as ahmad/larda#52 and moved here on 2026-09-08: it is a fleet-wide naming convention, so it belongs where fleet conventions live rather than inside one of the repositories it governs.

Scope

In: one naming convention for the DSN across ahmad/larda and ahmad/expiro, applied to the Forgejo repo secrets, the workflows, docs/CONFIGURATION.md and .env.example in each; a decision on whether the web build-time value and the api runtime value are one secret or two.
Out: changing GlitchTip projects or rotating the DSNs themselves; other repos' observability wiring; anything in amtronics/infrastructure-vps.

Decision needed before this can start

Renaming a Forgejo repo secret means creating the new one and deleting the old, which is provisioning work this loop does not do. Two questions, both for a human:

One name or two? GLITCHTIP_DSN for the api runtime and VITE_GLITCHTIP_DSN for the web build arg — separately settable, and honest that one is public in the bundle and one is not — or a single name in both repos.
Which repo moves? Aligning on larda's name changes expiro; aligning on split names changes both.

Once those are answered and the secrets exist under the chosen names, the workflow, documentation and .env.example changes are ordinary work.

Acceptance criteria

Given both repositories, when their workflows are read, then the DSN is referenced under the agreed name(s) and nothing references the retired one.
Given docs/CONFIGURATION.md in each repository, when it is read, then each name's scope and "where it lives" match where the value was actually stored.
Given a release of each app, when it builds and deploys, then error reporting still reaches GlitchTip from both the web bundle and the api.

### Context The same GlitchTip DSN is stored under two different secret names across the fleet, and in one repo a single name covers two scopes: - `ahmad/expiro` — the Forgejo repo secret is `VITE_GLITCHTIP_DSN`, consumed as a build arg (`release.yml:196`). - `ahmad/larda` — the repo secret is `GLITCHTIP_DSN`. `release.yml:196` maps it to the `VITE_GLITCHTIP_DSN` build arg for the web bundle, and `GLITCHTIP_DSN` is *also* the name of the api's runtime value from OpenBao `secret/larda` (`release.yml:344`, `deploy.yml:154`). Two costs. Someone wiring a third repo has no rule to copy — both existing repos are precedents and they disagree. And in `larda` the two uses cannot be given different values or rotated separately, because they share a name: the DSN baked into a public bundle and the one the server process holds are the same string by construction rather than by decision. Found while reviewing `infrastructure-vps#428`. Filed first as `ahmad/larda#52` and moved here on 2026-09-08: it is a fleet-wide naming convention, so it belongs where fleet conventions live rather than inside one of the repositories it governs. ### Scope - In: one naming convention for the DSN across `ahmad/larda` and `ahmad/expiro`, applied to the Forgejo repo secrets, the workflows, `docs/CONFIGURATION.md` and `.env.example` in each; a decision on whether the web build-time value and the api runtime value are one secret or two. - Out: changing GlitchTip projects or rotating the DSNs themselves; other repos' observability wiring; anything in `amtronics/infrastructure-vps`. ### Decision needed before this can start Renaming a Forgejo repo secret means creating the new one and deleting the old, which is provisioning work this loop does not do. Two questions, both for a human: 1. **One name or two?** `GLITCHTIP_DSN` for the api runtime and `VITE_GLITCHTIP_DSN` for the web build arg — separately settable, and honest that one is public in the bundle and one is not — or a single name in both repos. 2. **Which repo moves?** Aligning on `larda`'s name changes `expiro`; aligning on split names changes both. Once those are answered and the secrets exist under the chosen names, the workflow, documentation and `.env.example` changes are ordinary work. ### Acceptance criteria - [ ] Given both repositories, when their workflows are read, then the DSN is referenced under the agreed name(s) and nothing references the retired one. - [ ] Given `docs/CONFIGURATION.md` in each repository, when it is read, then each name's scope and "where it lives" match where the value was actually stored. - [ ] Given a release of each app, when it builds and deploys, then error reporting still reaches GlitchTip from both the web bundle and the api.

ahmad added the

state/needs-refinement

priority/P3

type/chore

size/S

labels

2026-09-08 19:46:50 +00:00

ahmad added a new dependency

2026-09-08 19:47:00 +00:00

ahmad/expiro#80 - feat: Report api crashes to GlitchTip

ahmad commented

2026-09-08 19:53:12 +00:00

Author

Owner

Decision, so this stops blocking ahmad/expiro#80.

Two names, not one. VITE_GLITCHTIP_DSN for the browser bundle, GLITCHTIP_DSN for an api runtime. They are not the same kind of value: the first is compiled into a public artefact and is readable by anyone who loads the page, the second is only ever held by the server. Collapsing them means one rotation touches both scopes, and a public value ends up in the store meant for private ones. The VITE_ prefix is also not decoration — it is what makes the bundler expose the value — so the web one cannot be renamed anyway.

No repository is renamed. ahmad/larda keeps GLITCHTIP_DSN for its api and maps it to the VITE_GLITCHTIP_DSN build arg for the web bundle; that mapping is correct and stays. ahmad/expiro keeps VITE_GLITCHTIP_DSN and adds GLITCHTIP_DSN when it gains an api reporter. Nothing loses a working secret and no deploy breaks on a name that moved.

Where each lives. The browser DSN is a public ingest address, so it belongs in the app's variables.yml as a Forgejo variable. The api DSN is a vault secret synced to OpenBao secret/<app>, which is how larda's was provisioned. Where a repo currently carries the browser DSN as a secret instead, that is a tidy-up to do when the repo is next touched, not a rename.

The rule for a third repo: VITE_GLITCHTIP_DSN — build arg, public, variable. GLITCHTIP_DSN — runtime, private, vault. That belongs in this repository's README beside the other fleet conventions, and this issue can carry that change.

Decision, so this stops blocking `ahmad/expiro#80`. **Two names, not one.** `VITE_GLITCHTIP_DSN` for the browser bundle, `GLITCHTIP_DSN` for an api runtime. They are not the same kind of value: the first is compiled into a public artefact and is readable by anyone who loads the page, the second is only ever held by the server. Collapsing them means one rotation touches both scopes, and a public value ends up in the store meant for private ones. The `VITE_` prefix is also not decoration — it is what makes the bundler expose the value — so the web one cannot be renamed anyway. **No repository is renamed.** `ahmad/larda` keeps `GLITCHTIP_DSN` for its api and maps it to the `VITE_GLITCHTIP_DSN` build arg for the web bundle; that mapping is correct and stays. `ahmad/expiro` keeps `VITE_GLITCHTIP_DSN` and *adds* `GLITCHTIP_DSN` when it gains an api reporter. Nothing loses a working secret and no deploy breaks on a name that moved. **Where each lives.** The browser DSN is a public ingest address, so it belongs in the app's `variables.yml` as a Forgejo variable. The api DSN is a vault secret synced to OpenBao `secret/<app>`, which is how larda's was provisioned. Where a repo currently carries the browser DSN as a secret instead, that is a tidy-up to do when the repo is next touched, not a rename. The rule for a third repo: **`VITE_GLITCHTIP_DSN` — build arg, public, variable. `GLITCHTIP_DSN` — runtime, private, vault.** That belongs in this repository's README beside the other fleet conventions, and this issue can carry that change.

ahmad added

state/ready

and removed

state/needs-refinement

labels

2026-09-08 19:53:22 +00:00

ahmad removed a dependency

2026-09-08 20:34:32 +00:00

ahmad/expiro#80 - feat: Report api crashes to GlitchTip

ahmad self-assigned this

2026-09-09 10:15:35 +00:00

ahmad added

state/in-progress

and removed

state/ready

labels

2026-09-09 10:15:35 +00:00

ahmad commented

2026-09-09 10:16:37 +00:00

Author

Owner

Taking this, on the decision above. It is smaller than the body's scope,
because the decision resolved most of it by not renaming anything.

What I checked first, rather than assuming from the workflows. Read
the actual storage back from the API for both repositories:

	Name	Stored as
`ahmad/expiro`	`VITE_GLITCHTIP_DSN`	Forgejo repo secret
`ahmad/larda`	`GLITCHTIP_DSN`	Forgejo repo secret

Neither has a GlitchTip variable. Both api runtime DSNs come from
OpenBao secret/<app>.

So two changes, one pull request each.

Here — the rule into the README's contract section:
VITE_GLITCHTIP_DSN build-time, public, a variable; GLITCHTIP_DSN
runtime, private, a vault secret. That is what a third repository has
to copy, and it is the part of this issue that outlives it.
ahmad/expiro — its docs/CONFIGURATION.md contradicts itself on
the row this issue is about: type says variable, "where it lives"
says Forgejo repo secret, and the API says secret. Acceptance
criterion two asks the document to match where the value is actually
stored, so the type becomes secret, with the move to a variable
recorded as the pending tidy-up the decision calls it rather than
written up as though it had happened.

ahmad/larda needs no change. Its single row already says one secret
feeding a build arg and a runtime value, which is exactly what it does
and what the decision blessed. I am not splitting it to satisfy a
symmetry the decision explicitly declined.

Not doing, and saying so: moving expiro's browser DSN from a secret
to a variable. That is provisioning — creating one and deleting the
other — which this loop does not do, and the decision already calls it a
tidy-up for whenever the repository is next touched for that purpose.

Taking this, on the decision above. It is smaller than the body's scope, because the decision resolved most of it by not renaming anything. **What I checked first, rather than assuming from the workflows.** Read the actual storage back from the API for both repositories: | | Name | Stored as | |---|---|---| | `ahmad/expiro` | `VITE_GLITCHTIP_DSN` | Forgejo repo **secret** | | `ahmad/larda` | `GLITCHTIP_DSN` | Forgejo repo **secret** | Neither has a GlitchTip **variable**. Both api runtime DSNs come from OpenBao `secret/<app>`. **So two changes, one pull request each.** 1. **Here** — the rule into the README's contract section: `VITE_GLITCHTIP_DSN` build-time, public, a variable; `GLITCHTIP_DSN` runtime, private, a vault secret. That is what a third repository has to copy, and it is the part of this issue that outlives it. 2. **`ahmad/expiro`** — its `docs/CONFIGURATION.md` contradicts itself on the row this issue is about: type says `variable`, "where it lives" says `Forgejo repo secret`, and the API says secret. Acceptance criterion two asks the document to match where the value is actually stored, so the type becomes `secret`, with the move to a variable recorded as the pending tidy-up the decision calls it rather than written up as though it had happened. **`ahmad/larda` needs no change.** Its single row already says one secret feeding a build arg and a runtime value, which is exactly what it does and what the decision blessed. I am not splitting it to satisfy a symmetry the decision explicitly declined. **Not doing, and saying so:** moving `expiro`'s browser DSN from a secret to a variable. That is provisioning — creating one and deleting the other — which this loop does not do, and the decision already calls it a tidy-up for whenever the repository is next touched for that purpose.

ahmad referenced this issue from a commit

2026-09-09 10:18:36 +00:00

docs: Record how the error-reporting DSN is named

ahmad referenced this issue from a commit

2026-09-09 10:18:39 +00:00

docs: Correct how the browser DSN is stored

ahmad referenced this issue from a pull request that will close it,

2026-09-09 10:19:10 +00:00

docs: Record how the error-reporting DSN is named #73

ahmad

2026-09-09 10:22:36 +00:00

closed this issue
added
state/in-review
and removed
state/in-progress
labels

ahmad commented

2026-09-09 12:45:53 +00:00

Author

Owner

Done. Two pull requests, both merged:

	PR	Merge
The convention, recorded	#73	`19fa5cd`
`ahmad/expiro`'s doc corrected	ahmad/expiro#83	`1490382`

The README's contract section now carries the rule a third repository
copies: VITE_GLITCHTIP_DSN — build time, public by construction, a
Forgejo variable. GLITCHTIP_DSN — runtime, private, an OpenBao secret.
With why collapsing them is the mistake, and why the VITE_ prefix means
the public one cannot be renamed anyway.

No repository was renamed and no secret moved, per the decision above.
What actually needed changing was smaller than the issue's original scope,
and one thing needed changing that the issue had not spotted: ahmad/expiro's
docs/CONFIGURATION.md typed VITE_GLITCHTIP_DSN as a variable while its
own "where it lives" column said Forgejo repo secret. Read back from the
actions API, it is a secret. Corrected, with the move to a variable recorded
as the pending tidy-up it is rather than written up as done.

ahmad/larda needed nothing: its single row already describes one secret
feeding a build arg and a runtime value, which is what it does and what the
decision blessed. Splitting it for symmetry would have contradicted the
decision.

Unverified, and not claimed: that a release of each app still reaches
GlitchTip from both the bundle and the api. No workflow, secret or build
argument changed in either repository, so nothing can have broken — but
that is an argument from an empty diff, not an observed event in GlitchTip.

**Done.** Two pull requests, both merged: | | PR | Merge | |---|---|---| | The convention, recorded | #73 | `19fa5cd` | | `ahmad/expiro`'s doc corrected | ahmad/expiro#83 | `1490382` | The README's contract section now carries the rule a third repository copies: **`VITE_GLITCHTIP_DSN` — build time, public by construction, a Forgejo variable. `GLITCHTIP_DSN` — runtime, private, an OpenBao secret.** With why collapsing them is the mistake, and why the `VITE_` prefix means the public one cannot be renamed anyway. **No repository was renamed and no secret moved**, per the decision above. What actually needed changing was smaller than the issue's original scope, and one thing needed changing that the issue had not spotted: `ahmad/expiro`'s `docs/CONFIGURATION.md` typed `VITE_GLITCHTIP_DSN` as a `variable` while its own "where it lives" column said `Forgejo repo secret`. Read back from the actions API, it is a secret. Corrected, with the move to a variable recorded as the pending tidy-up it is rather than written up as done. `ahmad/larda` needed nothing: its single row already describes one secret feeding a build arg and a runtime value, which is what it does and what the decision blessed. Splitting it for symmetry would have contradicted the decision. **Unverified, and not claimed:** that a release of each app still reaches GlitchTip from both the bundle and the api. No workflow, secret or build argument changed in either repository, so nothing can have broken — but that is an argument from an empty diff, not an observed event in GlitchTip.

ahmad added

state/done

and removed

state/in-review

labels

2026-09-09 12:45:53 +00:00

ahmad referenced this issue

2026-09-09 18:17:25 +00:00

docs: Record this repo's configuration and the consumer register #77