API REST

Releases e testes

Releases, notas da versão, casos e ciclos de teste.

  • GET /releases (tracker:read): releases com status, kind (version ou ota), stage (current é a que está no ar, uma por trilho: a versão e a OTA do projeto têm cada uma a sua; previous, approved, testing, development, planned, cancelled), stage_label (o nome na tela), is_next (a próxima a ir ao ar), datas, issues em aberto e a última decisão do Release Gate. Query: project e status (lista separada por vírgula).
  • GET /releases/{id} (tracker:read): a release com kind, stage, stage_label, is_next, o resumo da tela (summary: headline, context e next_step), as métricas e a sugestão do gate (gate.applies; em OTA sem BLOCKED registrado, gate.suggestion.decision é not_applicable e no lugar das métricas vem gate.validation, a contagem das issues: ready_for_qa, testing, approved, failed), a última decisão, as issues, os ciclos de teste e as notas da versão.
  • POST /releases (tracker:write): cria uma release, {"project": "MOB", "version": "2.7.0", "build": "...", "environment": "...", "planned_date": "AAAA-MM-DD", "notes": "...", "kind": "version"}; kind é version (o padrão) ou ota. Release que já foi ao ar (OTA enviada, deploy do backend, versão publicada fora do tracker) pode nascer em produção, sem o gate: "status": "production" e released_date (padrão: hoje). PO/PM ou admin. A versão é única no projeto: repetir o pedido devolve a release que já existe (200, already_existed: true), sem mudar nada nela. Para o CI registrar uma entrega: POST /releases, depois POST /issues/bulk com "action": "release" e as issues, e POST /releases/{id}/status.
  • POST /releases/{id}/status (tracker:write): {"status": "in_development"}. O caminho é planned → in_development → staging (em teste), e de approved para production; cancelled sai do caminho. OTA (kind: "ota") vai a production direto, de planned, in_development, staging ou approved, sem a decisão do gate, a não ser que a última decisão seja BLOCKED; a validação segue depois pelas issues vinculadas (o summary.next_step de GET /releases/{id} diz quantas estão em Pronto para QA, em teste, aprovadas e reprovadas). As outras releases chegam a approved pela decisão APPROVED do gate, registrada por uma pessoa na tela, e produção exige essa decisão. Fora desse caminho (approved direto, inclusive) só admin, com override_note.
  • POST /releases/{id}/move (tracker:write): {"to_project": "PLT"} move a release para outro projeto da empresa (ex.: os deploys do backend que nasceram no app vão para o projeto da plataforma). Leva histórico, decisões do gate e notas; as issues continuam vinculadas, mesmo as de outros projetos. PO/PM ou admin nos dois projetos; a versão não pode existir no destino e release com ciclo de teste não se move. MCP: move_release.
  • PUT /releases/{id}/notes (tracker:write): grava as notas da versão, o texto para o cliente que a tela copia e manda por e-mail: {"release_notes": "# App 2.7.0\n\n## Novidades\n\n- Agora dá para..."}. Markdown simples (# título, ## seção, - item; sem negrito nem links). Substitui o texto inteiro; vazio ou null volta ao rascunho gerado das issues resolvidas. PO/PM ou admin. A resposta traz release_notes e release_notes_saved. Não envia o e-mail.
  • GET /test-cases (tracker:read): casos de teste ativos. Query: project, q (parte do código ou do título) e include_archived.
  • POST /test-cases (tracker:write): cria um caso, {"project": "MOB", "title": "...", "module": "...", "priority": "high", "steps": [{"action": "...", "expected": "..."}]}. QA ou admin. O código (TC-MOB-0001) é gerado.
  • GET /test-cycles (tracker:read): ciclos mais recentes com o progresso. Query: project e status.
  • GET /test-cycles/{id} (tracker:read): o ciclo com cada caso e o resultado (pass, fail, blocked, in_progress, not_started), o comentário, quem testou e a issue aberta a partir do fail.
  • POST /test-cycles (tracker:write): cria um ciclo, {"project": "MOB", "name": "Regressão 2.7.0", "release": "2.7.0", "environment": "...", "cases": ["TC-MOB-0001"]}. Sem cases, entram todos os casos ativos do projeto. QA ou admin.
  • POST /test-cycles/{id}/results (tracker:write): resultados do CI, até 200 por pedido, {"results": [{"test_case": "TC-MOB-0001", "status": "fail", "comment": "...", "open_issue": true}]}. status: pass, fail, blocked ou in_progress; comentário obrigatório para fail e blocked. Com open_issue, o fail abre a issue já preenchida com o caso (ou devolve a que já existe); se a issue não abrir, o resultado fica gravado e o item volta com warning. Item a item, com recorded, failed e results. QA ou admin.
  • POST /test-cycles/{id}/status (tracker:write): {"action": "start" | "finish" | "cancel" | "reopen"}. Ciclo encerrado não aceita resultados até ser reaberto.