feat(ci): habilita publish do pns-core no npm#3
Merged
Conversation
Adiciona `packages/pns-core` ao input `packages` do publish job em `.github/workflows/ci.yml`. O campo estava vazio, motivo pelo qual o passo de publicação no npm nunca rodou após o release v1.0.0 (2026-04-26) — o registry continuou retornando 404 para @precisa-saude/pns mesmo com a tag e o GitHub release criados. Com o publish job ativo, o próximo release ciclado por semantic-release publicará o pacote no npm com `--provenance`.
|
🎉 This PR is included in version 1.1.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
4 tasks
rlueder
added a commit
that referenced
this pull request
May 13, 2026
…bump de versão (#6) Sem configuração explícita, semantic-release roda só com plugins padrão (commit-analyzer + npm + github) — calcula a próxima versão e cria a tag, mas **não commita** o bump no package.json. O workflow `_publish.yml` então faz checkout do commit de release, lê `packages/pns-core/package.json` (ainda em `0.1.0`), consulta `npm view @precisa-saude/pns@0.1.0` → já publicado → pula silenciosamente. Resultado: todas as 3 release cycles do pns (PRs #3, #4, #5) terminaram sem publicar versão nova no npm; o registry está travado em 0.1.0. Solução: traz a configuração canônica de [`tooling/.releaserc.cjs`](https://github.com/Precisa-Saude/tooling/blob/main/.releaserc.cjs) e o helper `scripts/sync-versions.cjs`, que juntos garantem: 1. Análise de commits conforme Conventional Commits (mesmas regras dos outros repos do ecossistema). 2. `@semantic-release/changelog` mantém CHANGELOG.md. 3. `@semantic-release/npm` (npmPublish: false — a publicação fica com `_publish.yml`) bumpa só a raiz. 4. `@semantic-release/exec` roda `scripts/sync-versions.cjs` para propagar a versão pra todo `packages/*` não-privado. 5. `@semantic-release/git` commita `package.json`, `packages/*/package.json` e `CHANGELOG.md` de volta no `main` com mensagem `chore(release): X.Y.Z [skip ci]`. 6. `@semantic-release/github` cria o release no GitHub. Após o merge deste PR, o próximo merge com `feat:`/`fix:` (ou esta mesma fix por si só) dispara um ciclo completo: semantic-release calcula a próxima versão a partir da tag `v1.0.0` existente, commita o bump no `main`, e `_publish.yml` faz checkout desse commit e publica no npm.
3 tasks
rlueder
added a commit
that referenced
this pull request
May 13, 2026
O guard `require_package_changes: true` pulava o release sempre que um PR mexia apenas em `.github/**` ou na config (era o caso de PR #6 e #7). Como `@semantic-release/git` só commita o bump de versão de volta no `main` quando o release roda, três PRs (#3, #4, #5) materializaram tags git mas nunca chegaram a publicar no npm. Cada novo PR de config para arrumar isso era também guarded out. pns só tem um pacote publicável (`pns-core`); o overhead de release no-op sobre mudanças de workflow é insignificante, e o custo de release pulado silenciosamente é alto. Setando o input para `false` no call do \`_release.yml\`. Outros repos com vários pacotes publicáveis podem manter o guard ativo.
precisa-saude-release-bot Bot
pushed a commit
that referenced
this pull request
May 13, 2026
## [1.3.0](v1.2.0...v1.3.0) (2026-05-13) ### Features * **ci:** sincroniza workflows com o template do tooling ([#7](#7)) ([c9b5b55](c9b5b55)), closes [#6](#6) [#30](https://github.com/Precisa-Saude/pns/issues/30) [#31](https://github.com/Precisa-Saude/pns/issues/31) ### Bug Fixes * **ci:** adiciona .releaserc.cjs para que semantic-release commite o bump de versão ([#6](#6)) ([019e7ea](019e7ea)), closes [#3](#3) [#4](#4) [#5](#5) * **ci:** desabilita o guard require_package_changes no release job ([#8](#8)) ([27e287a](27e287a)), closes [#6](#6) [#7](#7) [#3](#3) [#4](#4) [#5](#5)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resumo
Preenche o input
packagesdo publish job no CI — estava vazio, por isso@precisa-saude/pns@1.0.0nunca chegou ao npm registry (404 desde 2026-04-26).Contexto
v1.0.0existe (criada por semantic-release em 2026-04-26).v1.0.0existe.npm view @precisa-saude/pnsretorna 404 — publish job nunca rodou porque a entradapackages:estava vazia emci.yml.Plano após merge
Como este commit é um
feat:que toca.github/**(nãopackages/**), o guardrequire_package_changes: trueno_release.ymlvai pular o ciclo de release.Para forçar um release que publique:
packages/pns-core(qualquer mudança real) com tipofeat:oufix:→ semantic-release publicaráv1.0.1ouv1.1.0.gh workflow run publish-tag.yml -f tag=v1.0.0para publicar0.1.0(versão que ficou napackage.jsonno commit da tag). Mistura tag v1.0.0 com versão npm 0.1.0 — funcional mas não alinhado.Recomendado opção A.
Test plan
npm view @precisa-saude/pnsretorna versão