Skip to content

fix: injeta o Google client id nos builds de release do desktop - #464

Merged
johnlaff merged 1 commit into
mainfrom
fix/release-client-id
Aug 15, 2026
Merged

fix: injeta o Google client id nos builds de release do desktop#464
johnlaff merged 1 commit into
mainfrom
fix/release-client-id

Conversation

@johnlaff

Copy link
Copy Markdown
Owner

O quê / por quê

src/lib/env.ts e src/lib/api.ts assam VITE_GOOGLE_CLIENT_ID e VITE_GOOGLE_DESKTOP_CLIENT_KEY em tempo de build via import.meta.env (string vazia/null quando ausentes), mas .github/workflows/release.yml nunca passava esses valores para o tauri-action — o app publicado (confirmado nas builds v0.2.1 e v0.3.0) saía sem cliente OAuth configurado e não conseguia nem iniciar a conexão com o Google.

Os secrets do repositório VITE_GOOGLE_CLIENT_ID e VITE_GOOGLE_DESKTOP_CLIENT_KEY já estão cadastrados; este PR só faz o workflow referenciá-los por nome.

Mudança

Único passo de build do frontend/backend no workflow é o Build Tauri bundle (tauri-apps/tauri-action): ele roda npm run build (Vite, via beforeBuildCommand) e em seguida cargo build --release para o mesmo processo — o .exe portável (passo seguinte, só para Windows) é uma cópia do binário que esse passo já produziu, então não há um segundo lugar para injetar env.

Adicionadas ao env: desse passo:

  • VITE_GOOGLE_CLIENT_ID / VITE_GOOGLE_DESKTOP_CLIENT_KEY — consumidos pelo bundle Vite.
  • GOOGLE_CLIENT_SECRET (mesmo valor de VITE_GOOGLE_DESKTOP_CLIENT_KEY) — o backend Rust tem um fallback próprio embutido em tempo de compilação (option_env!("GOOGLE_CLIENT_SECRET") em src-tauri/src/oauth/pkce.rs::resolve_client_secret), usado pelo refresh de token em segundo plano. O frontend só repassa o secret no fluxo de conexão iniciado pelo usuário; sem esse fallback embutido, a conexão cairia a cada ~1h mesmo com o client id correto.

Como verificar

  • actionlint e zizmor (mesmas versões do workflows-lint.yml) rodados localmente contra release.yml: sem findings.
  • npm run privacy:scan: limpo (comando separado, antes de qualquer push).
  • Nenhum valor de secret foi impresso ou logado — só referências por nome.

O frontend assa VITE_GOOGLE_CLIENT_ID e VITE_GOOGLE_DESKTOP_CLIENT_KEY em
tempo de build (import.meta.env), mas o workflow de release não passava
esses valores para o tauri-action — o binário publicado saía sem cliente
OAuth configurado e não conseguia nem iniciar a conexão com o Google.

O mesmo passo também compila o binário Rust (cargo build via tauri-action),
que tem seu próprio fallback embutido em tempo de compilação
(GOOGLE_CLIENT_SECRET, via option_env! em oauth/pkce.rs) usado pelo refresh
de token em segundo plano. Sem ele a conexão cairia a cada ~1h no build de
release mesmo com o client id correto, já que o frontend só repassa o
secret no fluxo de conexão iniciado pelo usuário.
@johnlaff
johnlaff merged commit 2b23a40 into main Aug 15, 2026
8 checks passed
johnlaff added a commit that referenced this pull request Aug 15, 2026
O PR #464 fez os builds de release do desktop embutirem o Google client
id, mas seu squash entrou no main sem o prefixo Conventional Commits —
num PR de commit único, o GitHub usava a mensagem do commit (sem
prefixo, pela convenção do repo) como assunto do squash, e o
release-please descartou o conserto como "não user-facing": a 0.3.1
nunca nasceu.

Este PR conserta a causa e o sintoma: a configuração do repositório
passou a usar o título do PR como assunto do squash e o corpo do PR como
mensagem (o que também torna o Closes #N deliberado, nunca herdado de
commit antigo), o AGENTS.md documenta a regra, e o próprio squash deste
PR — com prefixo fix: — devolve ao release-please o lançamento pendente
que carrega o conserto do OAuth para os usuários da versão instalada.

Como verificar: após o merge, o release-please deve abrir o PR da
release 0.3.1 contendo este conserto no changelog.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant