Validar o Release de ponta a ponta com uma tag nova, sem re-run #5

New issue

Closed

opened 2026-10-10 17:19:47 -03:00 by caio · 1 comment

caio commented

2026-10-10 17:19:47 -03:00

Owner

Nenhuma tag passou no workflow de primeira até agora (v1.0.0 e v1.0.1 falharam; v1.0.2 só no re-run). A confirmação definitiva é a próxima tag (ex: v1.0.3, quando a develop for pra main) passar em todas as etapas na 1ª execução: validar tag → testes → pacote → deploy FTP → smoke → Release com zip.

Feito quando: o run da próxima tag ficar verde sem intervenção manual.

Nenhuma tag passou no workflow de primeira até agora (v1.0.0 e v1.0.1 falharam; v1.0.2 só no re-run). A confirmação definitiva é a próxima tag (ex: `v1.0.3`, quando a `develop` for pra `main`) passar em todas as etapas na 1ª execução: validar tag → testes → pacote → deploy FTP → smoke → Release com zip. **Feito quando:** o run da próxima tag ficar verde sem intervenção manual.

caio referenced this issue

2026-10-10 17:19:48 -03:00

Confirmar que o workflow de Release está funcionando #6

caio added the

ci-cd

label

2026-10-10 17:20:22 -03:00

caio referenced this issue

2026-10-10 17:21:51 -03:00

Auditar os runs do workflow Release (v1.0.0 → v1.0.2) e a versão em produção #3

caio referenced this issue

2026-10-10 17:38:49 -03:00

Confirmar que o workflow de Release está funcionando #6

caio added this to the Argos project

2026-10-10 17:46:22 -03:00

caio commented

2026-10-10 19:57:41 -03:00

Author

Owner

Validado com a v1.1.0 — run 33, tudo verde na 1ª execução, sem re-run:

Etapa	Resultado
Validar versão	ok
Testes (debian e ubuntu-latest)	ok
Backup do banco	`_backups/backup_v1.1.0_2026-10-10_225527_….sql.php`
Migrations	014 a 019 aplicadas
Conferência dos arquivos enviados	ok
Smoke test em produção	ok
Release no Forgejo	v1.1.0

Observação: a primeira rodada do smoke pegou 404 em três rotas da API (a CDN da Hostinger ainda servindo a resposta do período de manutenção); a repetição automática depois de 30s passou em tudo. É o mecanismo do próprio deploy funcionando, não um re-run do workflow — mas mostra que o ajuste de furar o cache (15143af) não cobre as rotas /api/.

Conferido de fora depois do deploy: rodapé do Painel em v1.1.0; PWA, Painel, Ikarus37 e os arquivos novos respondendo 200; com a chave pública do app, painel_usuarios.php e situacao.php respondem 403 e as rotas do app sem sessão respondem 401.

Antes do deploy as seis migrations foram ensaiadas numa cópia do backup de produção em MariaDB 10.11, com a suíte inteira passando em cima.

**Validado com a `v1.1.0`** — [run 33](https://cosmos.simioni.dev.br/cidit/projeto-argos/actions/runs/33), tudo verde na 1ª execução, sem re-run: | Etapa | Resultado | |---|---| | Validar versão | ok | | Testes (debian e ubuntu-latest) | ok | | Backup do banco | `_backups/backup_v1.1.0_2026-10-10_225527_….sql.php` | | Migrations | 014 a 019 aplicadas | | Conferência dos arquivos enviados | ok | | Smoke test em produção | ok | | Release no Forgejo | [v1.1.0](https://cosmos.simioni.dev.br/cidit/projeto-argos/releases/tag/v1.1.0) | Observação: a primeira rodada do smoke pegou `404` em três rotas da API (a CDN da Hostinger ainda servindo a resposta do período de manutenção); a repetição automática depois de 30s passou em tudo. É o mecanismo do próprio deploy funcionando, não um re-run do workflow — mas mostra que o ajuste de furar o cache (15143af) não cobre as rotas `/api/`. Conferido de fora depois do deploy: rodapé do Painel em `v1.1.0`; PWA, Painel, Ikarus37 e os arquivos novos respondendo 200; com a chave pública do app, `painel_usuarios.php` e `situacao.php` respondem 403 e as rotas do app sem sessão respondem 401. Antes do deploy as seis migrations foram ensaiadas numa cópia do backup de produção em MariaDB 10.11, com a suíte inteira passando em cima.

caio closed this issue

2026-10-10 19:57:42 -03:00

caio referenced this issue

2026-10-10 19:57:44 -03:00

Confirmar que o workflow de Release está funcionando #6