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

Conversation 0 Commits 1 Files Changed 1

+23 -12

1 Commits

Author	SHA1	Message	Date
synAdminandClaude Opus 5	903a1d8b76	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 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>	2026-09-11 14:17:51 -05:00

Author

SHA1

Message

Date

synAdminandClaude Opus 5

903a1d8b76

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

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>

2026-09-11 14:17:51 -05:00

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