chore(qa): read the Google credentials from the stack, like every other secret #355

2026-09-11T14:18:12-05:00

bermudalamb commented

2026-09-11 14:18:12 -05:00

QA_GOOGLE_CLIENT_ID and QA_GOOGLE_CLIENT_SECRET were set on the QA stack and went nowhere. #340 hardcoded the container's values empty rather than reading anything:

- GOOGLE_CLIENT_ID=
- GOOGLE_CLIENT_SECRET=

The button stayed missing, correctly, but for a reason the file gave no way to discover. Every other secret in it reads a QA_-prefixed stack variable; these two were the odd ones out. That cost a QA deploy, and the next one would have cost the same again.

What changed

They read the stack now, the way the rest of the file does:

- GOOGLE_CLIENT_ID=${QA_GOOGLE_CLIENT_ID:-}
- GOOGLE_CLIENT_SECRET=${QA_GOOGLE_CLIENT_SECRET:-}

Production already read its pair from the stack and is unchanged. The QA variable documentation at the top of the file gains an entry in the same style as the others.

Wiring is not enabling

Leave both stack variables unset until QA moves off *.bermudalamb.synology.me. The comment in the file now leads with this.

Google refuses a redirect URI whose host is not under a domain whose ownership has been proved by DNS, and nobody can prove ownership of that one, because Synology owns the registrable domain above it. Same wall as #285. Setting them today produces a button that fails at Google with redirect_uri_mismatch, and there is no console entry that could satisfy it.

Once #313 moves QA to qa.redefined-designs.com it is three steps and no code:

Set the two stack variables.
Point PUBLIC_URL at the new host.
Add https://qa.redefined-designs.com/api/auth/google/callback under Clients.

Testing

Both files still parse as YAML, both substitutions resolve to the intended stack variables, and the compose environment guard passes.

🤖 Generated with Claude Code

`QA_GOOGLE_CLIENT_ID` and `QA_GOOGLE_CLIENT_SECRET` were set on the QA stack and went nowhere. #340 hardcoded the container's values empty rather than reading anything: ```yaml - GOOGLE_CLIENT_ID= - GOOGLE_CLIENT_SECRET= ``` The button stayed missing, correctly, but for a reason the file gave no way to discover. Every other secret in it reads a `QA_`-prefixed stack variable; these two were the odd ones out. That cost a QA deploy, and the next one would have cost the same again. ## What changed They read the stack now, the way the rest of the file does: ```yaml - GOOGLE_CLIENT_ID=${QA_GOOGLE_CLIENT_ID:-} - GOOGLE_CLIENT_SECRET=${QA_GOOGLE_CLIENT_SECRET:-} ``` Production already read its pair from the stack and is unchanged. The QA variable documentation at the top of the file gains an entry in the same style as the others. ## Wiring is not enabling **Leave both stack variables unset until QA moves off `*.bermudalamb.synology.me`.** The comment in the file now leads with this. Google refuses a redirect URI whose host is not under a domain whose ownership has been proved by DNS, and nobody can prove ownership of that one, because Synology owns the registrable domain above it. Same wall as #285. Setting them today produces a button that fails at Google with `redirect_uri_mismatch`, and there is no console entry that could satisfy it. Once #313 moves QA to `qa.redefined-designs.com` it is three steps and no code: 1. Set the two stack variables. 2. Point `PUBLIC_URL` at the new host. 3. Add `https://qa.redefined-designs.com/api/auth/google/callback` under Clients. ## Testing Both files still parse as YAML, both substitutions resolve to the intended stack variables, and the compose environment guard passes. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

bermudalamb added 1 commit 2026-09-11 14:18:13 -05:00

chore(qa): read the Google credentials from the stack, like every other secret

SonarQube Analysis / sonarqube (pull_request) Failing after 28m14s

Details

Linting / lint (pull_request) Successful in 3m28s

Details

903a1d8b76

QA_GOOGLE_CLIENT_ID and QA_GOOGLE_CLIENT_SECRET were set on the QA stack and went nowhere, because #340 hardcoded the container's values empty rather than reading anything. The button stayed missing, correctly, but for a reason the file gave no way to discover: every other secret in it is read from a QA_-prefixed stack variable, and these two were the odd ones out.

So they are wired the way the rest of the file works. The deploy that prompted this cost nothing except time, and the next one would have cost the same again.

Wiring them is not the same as enabling them, and the comment now leads with that. **Leave both stack variables unset until QA moves off *.bermudalamb.synology.me.** Google refuses a redirect URI whose host is not under a domain whose ownership has been proved by DNS, and nobody can prove ownership of that one, because Synology owns the registrable domain above it — the same wall #285 hit with Cloudflare. Setting them today produces a button that fails at Google with redirect_uri_mismatch, and there is no console entry that could satisfy it.

Once #313 moves QA to qa.redefined-designs.com it is three steps and no code: set the two variables, point PUBLIC_URL at the new host, and add the matching callback under Clients in the Google Auth Platform.

Production already read its pair from the stack and is unchanged. The QA variable documentation at the top of the file gains an entry, matching the style of the others.

Verified: both files still parse as YAML, both substitutions resolve to the intended stack variables, and the compose environment guard passes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

bermudalamb merged commit c9dccfe4a2 into main

2026-09-11 14:19:21 -05:00

bermudalamb deleted branch chore/qa-google-credentials-from-stack

2026-09-11 14:19:21 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#355