0028 — Adota o native por padrão (ADR central 0033)¶
Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-09-14 · Decidido em: 2026-09-14
Decisão local do
bi-comercial-xlsque aponta a decisão CENTRAL 0033 da casa. Os números não se correspondem.
Contexto¶
Server Micronaut da casa é native por padrão, e jar só entra com motivo registrado: um bloqueio de native numa decisão do app, ou host sem a arquitetura do binário (ADR central 0033, que substitui a central 0022 espelhada na local 0021). Este app não tem bloqueio de native aberto: a leitura de XLSX é FastExcel (0020), a config de build está na 0021 e o domínio principal serve o binário native.
Decisão¶
O build.targets do docs/app.json contém só native, e o .github/workflows/pipeline.yml segue a
variante native do template: sem o job build_jar e sem o step de deploy jar. O Dockerfile JVM fica
no repo como par do Dockerfile.native, para build e diagnóstico locais; a guarda de paridade do
pipeline.yml confere os dois.
Consequências¶
- Não há motivo de jar a registrar: nenhum bloqueio de native está aberto, e o e2e native cobre a superfície do binário.
- A saída de emergência é a tag imutável
fonte.xadm.biz/xadm/onpetro-xls:<sha>-native, não um deploy jar. O procedimento está no runbook Deploy. - O recurso jar (
excel-jar.onpetro.xadm.biz) deixa de receber imagem nova; desligá-lo é operação de infraestrutura, fora deste repo. Religar a perna JVM exige release comjarnobuild.targetse o motivo registrado, nunca o recurso parado com a imagem velha. - O deploy segue pelo control-plane da local 0026, só com o
alvo
native; o alvojarque ela cita sai por esta decisão. - Este RD é ponteiro: divergência de mérito sobre native × jar se resolve no ADR central 0033.
Alternativas consideradas¶
- Manter o jar por dispatch manual, como fallback: descartado. A 0033 exige motivo registrado para o jar, e a tag imutável do native já cobre o rollback.