메뉴
Lança uma nova versão do SAPOS — merge na main, tag anotada, label e issues no GitHub, release publicada. Use quando um ramo estiver homologado e pronto para virar versão, ou quando precisar conferir como as releases anteriores foram feitas.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | release |
| description | Lança uma nova versão do SAPOS — merge na main, tag anotada, label e issues no GitHub, release publicada. Use quando um ramo estiver homologado e pronto para virar versão, ou quando precisar conferir como as releases anteriores foram feitas. |
Sequência para transformar um ramo pronto em versão publicada. O passo final — o deploy em produção — é do mantenedor; a skill vai até a release no GitHub.
Não comece sem isto:
bundle exec rspec, ~12 min).homologacao).main sincronizada com origin/main: git rev-list --left-right --count origin/main...main → 0 0.git log --oneline <tag_anterior>..<ramo>
git log <tag_anterior>..<ramo> --format='%h %s%n%b' | grep -iE '#[0-9]+' | sort -u
Separe as issues atendidas das apenas citadas. Um commit que diz "isso fica para issue própria (#626)" não atende a #626 — mencionar não é entregar.
Trabalho de vulnerabilidade não tem issue (ver AGENTS.md): vai aparecer
como commits sem referência. Isso é esperado, e o passo 6 diz como descrevê-lo.
Quem define é o mantenedor. Se ele não informar, proponha o incremento de patch
sobre a última tag (git tag -l --sort=-v:refname | head -3; 7.15.20 → 7.15.21)
e peça confirmação antes de criar a tag — o incremento pode não ser de patch.
git checkout main
git merge --ff-only <ramo>
git push origin main
O --ff-only é proposital: pelo modelo de ramos (CONTRIBUTING.md), o ramo
já mergeou a main nele antes do PR, então o merge tem que ser
fast-forward. Se o git recusar, não force nem faça merge commit — o ramo está
desatualizado e precisa integrar a main primeiro, com a suíte rodada de novo.
Nem toda release passa por PR; quando o mantenedor dispensa, o merge é direto.
git tag -a 7.15.21 -m "7.15.21"
git push origin 7.15.21
Sempre anotada (-a), nunca leve. As tags antigas têm mensagem vazia e a
7.15.19 tem o próprio número; use o número.
A tag não é decorativa: config/environment.rb:12 deriva APP_VERSION de
git describe --tag --always em tempo de execução, então é ela que aparece no
rodapé da aplicação.
gh label create 7.15.21 --color 0e8a16 --repo gems-uff/sapos
gh issue edit <N> --add-label 7.15.21
gh issue close <N> --reason completed
0e8a16 para todo label de versão — é o que dá o verde uniforme na lista.7.15.19 e segue aberta). Só feche o que
a versão de fato encerra.completed, sem comentário de encerramento — é o padrão do
repositório.gh api repos/gems-uff/sapos/releases \
-f tag_name=7.15.21 \
-f name='' \
-f body='Issues atendidas: https://github.com/gems-uff/sapos/issues?q=label%3A7.15.21' \
-F draft=false -F prerelease=false
O nome é vazio — o GitHub exibe a tag. Por isso a chamada é pela API: o
gh release create quer título.
O corpo aponta para a consulta do label, e não para uma lista escrita à mão, que
envelhece. Repare no %3A — é o : de label:7.15.21 codificado.
Quando a versão traz trabalho sem issue (o caso das vulnerabilidades), descreva em prosa antes do link e troque o rótulo dele:
Atualização do Rails de 7.1.6 para 7.2.3.1.
Demais issues atendidas: https://github.com/gems-uff/sapos/issues?q=label%3A7.15.21
Sem isso, a release diz "issues atendidas" sobre uma versão cuja mudança principal não está em issue nenhuma. Para vulnerabilidade, descreva a atualização (gem, de → para) sem citar CVE nem descrever o ataque.
gh release list --limit 3 # a nova deve aparecer como Latest
gh issue list --label 7.15.21 --state all
Passe a tag certa. Uma versão errada exibida em produção já foi rastreada até a tag passada no deploy, não ao Passenger. Depois de subir, confira o rodapé da aplicação.
git fetch --prune.Compara o SAPOS antes e depois de uma mudança em homologação, capturando telas, PDFs e planilhas nas duas versões e apontando o que divergiu. Use ao validar upgrade de dependência, atualização de framework ou refatoração ampla, quando a suíte verde não é evidência suficiente.
Mede o efeito de uma mudança localmente, comparando a suíte antes e depois. Use ao refatorar, atualizar dependência, corrigir bug ou implementar feature — sempre que for preciso separar "o que eu mudei" de "o que já estava assim".
Sobe um MariaDB local fiel ao de produção e roda a suíte contra ele, em vez do SQLite. Use ao mexer em consulta SQL, validação de unicidade, ordenação, migration ou qualquer coisa cujo comportamento dependa do banco.