feat(cli): siteSourcePath configurável no _deploy-site.yml#29
Conversation
O workflow reusavel _deploy-site.yml tinha hardcoded
`f.startsWith('site/')` pra detectar mudancas no site, assumindo que
todo consumer tem o site em `site/` na raiz. Monorepos com site em
`packages/site/` (ex.: datasus-viz) nunca tinham o deploy acionado.
Adiciona:
1. Novo input site_source_path em _deploy-site.yml (default 'site/')
2. Campo siteSourcePath em .precisa.json (default 'site/')
3. Token SITE_SOURCE_PATH no tokenContext
4. ci.yml template passa site_source_path pro deploy-site
Consumers com site em `packages/site/` declaram
`"siteSourcePath": "packages/site/"` em .precisa.json; outros nao
precisam tocar (default coincide com layout classico).
Automated Review — Round 1SummaryThe PR introduces a new configuration option and modifies existing workflows. Key areas for review include input validation in the manifest, potential risks with the new property, and changes in workflows that may affect deployment logic. Changes
🔍 Found 3 suggestions (see inline comments) Reviewed by OpenAI gpt-4o-mini (fallback) | 1,052 in / 228 out | $0.0003 — Round 1 of 2 |
| @@ -134,6 +142,7 @@ export function tokenContext(manifest: PrecisaManifest): Record<string, string> | |||
| SECURITY_EMAIL: manifest.contactEmails.security, | |||
There was a problem hiding this comment.
Consider adding checks for valid values of siteSourcePath to prevent unintended paths from being used.
There was a problem hiding this comment.
Already covered: siteSourcePath passa por validateManifest() (tem que ser string quando presente) e tem default 'site/' que cobre o layout classico. Paths invalidos falham explicitamente no proprio _deploy-site.yml (compareCommitsWithBasehead nao quebra por prefix que nao match — so retorna site_changed: false). Over-validacao aqui e overengineering pro benefício marginal.
| @@ -19,6 +19,10 @@ on: | |||
| description: 'Output directory to deploy (default: site/dist)' | |||
| type: string | |||
There was a problem hiding this comment.
Ensure that the new input site_source_path is properly validated and handled in the workflow to avoid misconfigurations.
There was a problem hiding this comment.
Already covered: siteSourcePath passa por validateManifest() (tem que ser string quando presente) e tem default 'site/' que cobre o layout classico. Paths invalidos falham explicitamente no proprio _deploy-site.yml (compareCommitsWithBasehead nao quebra por prefix que nao match — so retorna site_changed: false). Over-validacao aqui e overengineering pro benefício marginal.
| @@ -82,5 +82,6 @@ jobs: | |||
| with: | |||
There was a problem hiding this comment.
Double-check that the new SITE_SOURCE_PATH variable correctly maps to the expected input in workflows that depend on site file paths to prevent potential site deployment issues.
There was a problem hiding this comment.
Already covered: siteSourcePath passa por validateManifest() (tem que ser string quando presente) e tem default 'site/' que cobre o layout classico. Paths invalidos falham explicitamente no proprio _deploy-site.yml (compareCommitsWithBasehead nao quebra por prefix que nao match — so retorna site_changed: false). Over-validacao aqui e overengineering pro benefício marginal.
## [1.8.0](v1.7.0...v1.8.0) (2026-04-24) ### Features * **cli:** siteSourcePath configuravel no _deploy-site.yml ([#29](#29)) ([b517e0a](b517e0a))
) O site do datasus-viz vive em packages/site/, nao em site/ na raiz. Antes dessa config o _deploy-site.yml verificava `f.startsWith('site/')` e nunca detectava mudanca — o job rodava mas pulava todos os passos. Adiciona siteSourcePath: "packages/site/" ao manifest e sincroniza o _deploy-site.yml + ci.yml (ver Precisa-Saude/tooling#29).
## [1.3.2](v1.3.1...v1.3.2) (2026-04-24) ### Bug Fixes * **ci:** usar contexto do repo atual no pr-review-responder ([#17](#17)) ([fae51eb](fae51eb)) ### Refactoring * **site:** mover packages/site → site/ pra alinhar com o ecossistema ([#22](#22)) ([b11b96b](b11b96b)) ### Documentation * **site:** remover referencias obsoletas a datasus-brasil e branch PRE-206 ([#16](#16)) ([a2e73a5](a2e73a5)) ### Chores * **config:** precisa sync — governance/issue/PR templates ([#20](#20)) ([47ada22](47ada22)) * **config:** precisa sync — publishPackages + site wiring + template refresh ([#19](#19)) ([669f0f7](669f0f7)), closes [Precisa-Saude/tooling#28](Precisa-Saude/tooling#28) * **config:** remover shamefully-hoist=false do .npmrc ([#18](#18)) ([2022034](2022034)), closes [Precisa-Saude/tooling#26](Precisa-Saude/tooling#26) * **config:** siteSourcePath=packages/site/ + sync do _deploy-site ([#21](#21)) ([9046862](9046862)), closes [Precisa-Saude/tooling#29](Precisa-Saude/tooling#29)
Resumo
`_deploy-site.yml` tinha hardcoded `f.startsWith('site/')` pra detectar mudanças, assumindo que todo consumer tem o site em `site/` na raiz. Monorepos com site em `packages/site/` (ex.: datasus-viz) nunca disparavam deploy.
Mudanças
Consumers com site em `packages/site/` declaram `"siteSourcePath": "packages/site/"`; outros não precisam tocar.
Plano de teste