Runbook | Publicar / Ressincronizar Wikis
Como o pipeline de publicação funciona e o que fazer quando ele falha.
Visão geral do pipeline
Vault Obsidian (Google Drive)
│
│ rclone sync 3x/dia + on-push
▼
GitHub repo (colliers-costal-wiki) → content/
│
│ quartz build --matrix [internal, client, board]
▼
3 builds HTML separados
│
│ deploy Cloudflare Pages
▼
3 wikis: internal.* client.* board.*
- Sync:
rcloneroda de hora em hora (cron 09/12/17 BRT) + on-push. - Build: GitHub Actions roda Quartz 3x em paralelo (matrix), cada um com filtro de audiência.
- Deploy: cada output vira um projeto Cloudflare Pages distinto.
Gatilhos de ação
A. Mudança material no vault
Quando: você acabou de fazer uma mudança estrutural (nova pasta, renomeação, novo folder note, mudança no publish-contract).
Ação:
- Confirmar que o rclone
--excludecontinua válido (nada crítico novo bloqueado ou coisa privada publicada por erro) - Esperar próximo sync automático (máximo 3h) ou acionar manualmente via GitHub Actions → Run workflow
- Verificar o build nos 3 projetos Cloudflare — abrir cada wiki e validar que a nova página apareceu
- Checar Network / Console da wiki cliente para garantir que nenhum link aponta para conteúdo
[internal]quebrado
B. Arquivo que não deveria publicar está aparecendo
Diagnóstico rápido:
- O arquivo tem
publish:no frontmatter? Se sim, está com valor correto? - Tem tag
#sensivel? - O path está na denylist absoluta do publish-contract §1?
- O rclone
--excludeem wiki.yml cobre o path?
Ação: adicionar publish: none no frontmatter OU tag #sensivel OU atualizar o rclone exclude. Commit e esperar próximo build.
C. Build Quartz falhou
Primeiro lugar para olhar: GitHub Actions → último run com ❌.
Causas comuns:
| Sintoma | Causa provável | Fix |
|---|---|---|
| ”Module not found” | Dependência faltando no Quartz config | Atualizar package.json do repo wiki |
| ”Link doesn’t exist” em build-time | Link quebrado no vault | Buscar no vault pelo link e corrigir ou marcar como [[futuro:X]] |
| ”YAML parse error” | Frontmatter mal formatado em algum .md | Buscar arquivo recém-editado e validar YAML |
| Build roda mas deploy Cloudflare falha | Token CF expirado | Regenerar CLOUDFLARE_API_TOKEN no Settings → Secrets |
| ”rclone: config not found” | Secret VAULT_REMOTE_CONFIG ausente | Repopular secret com saída de rclone config |
D. Conteúdo publicado está desatualizado
Verificar na ordem:
- O arquivo foi atualizado no Google Drive? (o vault é a fonte)
- O rclone sync trouxe a versão nova? (checar timestamp do último run)
- O Quartz build rodou depois do sync?
- O Cloudflare Pages deployou o novo build?
- Cache do browser/CDN atrapalha? (hard reload / purge CF cache)
Se após todos os passos acima ainda está desatualizado, acionar workflow manualmente no GitHub Actions.
E. Precisa publicar algo com urgência (não pode esperar 3h)
- Commit da mudança no vault (via Drive → rclone, ou direto no repo wiki se for emergência)
- GitHub Actions →
Build e deploy das wikis→Run workflow→ branchmain - Acompanhar — build + deploy leva ~5-10 min
- Verificar URL ao vivo após deploy
Como adicionar uma nova “wiki” (nova audiência)
Procedimento raro — adicionar uma 4ª wiki (ex: fornecedores, auditoria externa).
- Decisão registrada em decisoes
- Atualizar publish-contract §1-2 com nova audiência
- Atualizar audience-scheme
- Criar 4º projeto no Cloudflare Pages
- Atualizar matrix no wiki.yml
- Atualizar secrets no GitHub se nova conta CF necessária
- Rodar um dry-run e validar que a audiência só recebe o que deveria
Lições aprendidas / antipadrões
| Antipadrão | Consequência | Lição |
|---|---|---|
| Commit no repo wiki direto, sem passar pelo vault Obsidian | Próximo rclone sobrescreve a edição | Sempre editar no Obsidian (vault = fonte) |
Adicionar publish: [client] sem internal | Arquivo nunca aparece na interna (onde Anouk valida) | Sempre incluir internal na lista |
Tag #sensivel aplicada como string sensivel (sem #) | Não ativa denylist | Sempre com # |
| Editar quartz.config.ts e esquecer de testar preview local | Build production quebra | Rodar preview.sh antes de commit |
Critério de pronto (de uma publicação)
- Mudança aparece na wiki interna
- Mudança aparece na wiki cliente (se
publish:inclui client) - Mudança aparece na wiki board (se
publish:inclui board) - Links internos funcionam (não há 404 em cross-link válido)
- Arquivos
[internal]NÃO estão acessíveis em client/board (validar com view-source ou abrindo sem login)