feat: item 7 do roadmap -- orquestração com runner externo #56
Loading…
Reference in a new issue
No description provided.
Delete branch "feature/runner-orchestration"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Auditoria prévia (mesma disciplina do item 6) confirmou zero código/docs pro protocolo de orquestração — só achou um design diferente e já documentado (ADR-0012,
TestCheck: o Cockpit chama HTTP pra fora sob agendamento/clique).Decisões confirmadas com o usuário (AskUserQuestion)
O que entra
Novo módulo
backend/modules/orchestration/:Runner(nome único + URL base) eRunnerJob— ciclo de vidaQUEUED/RUNNING/COMPLETED/FAILED, deliberadamente separado do outcome de teste (PASS/FAIL/etc, que continua emTestRunStepvia o contrato de ingestão que já existe, item 6).client.pyisola as 4 chamadas HTTP saintes (GET /health,GET /suites,POST /runs,GET /runs/{id}), mesmo padrão deai_client.py/hubspot_client.py.GET /api/runner-jobs/{id}é a própria checagem ao vivo contra o runner, best-effort (mantém o último status conhecido se o runner estiver inalcançável).(Runner.name, external_job_id)contraTestRun.automation_source/external_run_id, os mesmos campos quePOST /api/automation/runsjá grava. Zero acoplamento entremodules/orchestrationemodules/automation— nenhum dos dois importa o outro (confirmado por teste de integração completo).Frontend: tela nova
Runners.tsx(master-detail, mesmo padrão de Library/AutomationDiscoveries) — registrar runner, ver saúde, listar suítes, disparar execução, acompanhar jobs com link direto pra Run gerada quando o resultado chega.Verificação
pytest -n auto— 190 passed (14 testes novos, incluindo o teste de integração Job→TestRun sem acoplamento). Suíte de arquitetura confirma que o módulo novo respeita as mesmas fronteiras Core dos demais.tsc --noEmit,eslint,vitest— 131 passed (6 testes novos),build,build-storybook— todos ok.QUEUED→RUNNING→COMPLETEDvia "Atualizar" → mock publica resultado emPOST /api/automation/runs→ link "Ver Run #N" aparece sozinho → Run real com os 2 passos (1 PASS, 1 FAIL) certinha na tela que já existia, sem nenhuma mudança nela.Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
Auditoria previa (mesma disciplina do item 6) confirmou zero codigo/docs pro protocolo de orquestracao -- so achou um design DIFERENTE e ja documentado (ADR-0012, TestCheck: o Cockpit chama HTTP pra fora sob agendamento/clique). Decisao do usuario via AskUserQuestion: os dois coexistem (resolvem problemas diferentes -- TestCheck e checagem leve de endpoint HTTP, este item e orquestracao de suites reais tipo pytest/Playwright/Cypress que precisam de um ambiente que o Cockpit nao tem), e o escopo desta rodada e so o lado Cockpit, validado com um runner-mock (sem construir um runner de producao de verdade). Novo modulo backend/modules/orchestration/: - Runner (nome unico + URL base) e RunnerJob (ciclo de vida QUEUED/ RUNNING/COMPLETED/FAILED -- deliberadamente separado do outcome de teste PASS/FAIL/etc, que continua vivendo em TestRunStep via o contrato de ingestao que ja existe). - client.py isola as 4 chamadas HTTP saintes (GET /health, GET /suites, POST /runs, GET /runs/{id}), mesmo padrao de ai_client.py/hubspot_client.py. - Sem polling em background/worker novo (restricao do roadmap): cada GET /api/runner-jobs/{id} e a propria checagem ao vivo contra o runner, best-effort (mantem o ultimo status conhecido se o runner estiver inalcancavel, nunca quebra a leitura). - Vinculo Job -> TestRun NUNCA e uma FK guardada -- resolvido ao vivo comparando (Runner.name, external_job_id) contra TestRun.automation_source/external_run_id, os mesmos campos que POST /api/automation/runs (item 6) ja grava. Zero acoplamento entre modules/orchestration e modules/automation -- nenhum dos dois importa o outro, confirmado por teste de integracao completo (dispara job, simula o runner publicando resultado pelo endpoint que ja existe, confere que o vinculo aparece sozinho). Frontend: tela nova Runners.tsx (master-detail, mesmo padrao de Library/AutomationDiscoveries) -- registrar runner, ver saude (online/ inalcancavel), listar suites, disparar execucao, acompanhar jobs com link direto pra Run gerada quando o resultado chega. Verificacao: backend pytest -n auto (190 passed, 14 testes novos em test_orchestration.py, incluindo o teste de integracao Job->TestRun sem acoplamento), suite de arquitetura confirma que o novo modulo respeita as mesmas fronteiras Core dos demais. Frontend tsc/lint/vitest (131 passed, 6 testes novos)/build/build-storybook -- todos ok. Testado manualmente ponta a ponta com um runner-mock de verdade (script FastAPI descartavel, fora do repo): registrar -> saude "Online" -> suites reais listadas -> disparar job -> acompanhar QUEUED->RUNNING->COMPLETED via "Atualizar" -> mock publica resultado em POST /api/automation/runs -> link "Ver Run #N" aparece sozinho -> Run real com os 2 passos (1 PASS, 1 FAIL) certinha na tela que ja existia, sem nenhuma mudanca nela. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>