API REST

Releases y pruebas

Releases, notas de la versión, casos y ciclos de prueba.

  • GET /releases (tracker:read): releases con estado, kind (version u ota), stage (current es la que está en producción, una por carril: la versión y la OTA del proyecto tienen cada una la suya; previous, approved, testing, development, planned, cancelled), stage_label (el nombre en la pantalla), is_next (la próxima en salir), fechas, issues abiertas y la última decisión del Release Gate. Query: project y status (lista separada por comas).
  • GET /releases/{id} (tracker:read): la release con kind, stage, stage_label, is_next, el resumen de la pantalla (summary: headline, context y next_step), las métricas y la sugerencia del gate (gate.applies; en una OTA sin BLOCKED registrado, gate.suggestion.decision es not_applicable y en lugar de las métricas viene gate.validation, el conteo de las issues: ready_for_qa, testing, approved, failed), la última decisión, las issues, los ciclos de prueba y las notas de la versión.
  • POST /releases (tracker:write): crea una release, {"project": "MOB", "version": "2.7.0", "build": "...", "environment": "...", "planned_date": "AAAA-MM-DD", "notes": "...", "kind": "version"}; kind es version (el de por defecto) u ota. Una release que ya salió (OTA enviada, deploy del backend, versión publicada fuera de tracker) puede nacer en producción, sin el gate: "status": "production" y released_date (por defecto: hoy). PO/PM o admin. La versión es única en el proyecto: repetir el pedido devuelve la release que ya existe (200, already_existed: true), sin cambiar nada en ella. Para que el CI registre una entrega: POST /releases, después POST /issues/bulk con "action": "release" y las issues, y POST /releases/{id}/status.
  • POST /releases/{id}/status (tracker:write): {"status": "in_development"}. El camino es planned → in_development → staging (en prueba), y de approved a production; cancelled sale del camino. Una OTA (kind: "ota") va a production directo, desde planned, in_development, staging o approved, sin la decisión del gate, a menos que la última decisión sea BLOCKED; la validación sigue después por las issues vinculadas (el summary.next_step de GET /releases/{id} dice cuántas están en Listo para QA, en prueba, aprobadas y rechazadas). Las demás releases llegan a approved por la decisión APPROVED del gate, registrada por una persona en la pantalla, y producción exige esa decisión. Fuera de ese camino (approved directo, incluido) solo un admin, con override_note.
  • POST /releases/{id}/move (tracker:write): {"to_project": "PLT"} mueve la release a otro proyecto de la empresa (ej.: los deploys del backend que nacieron en la app van al proyecto de la plataforma). Lleva el historial, las decisiones del gate y las notas; las issues siguen vinculadas, incluso las de otros proyectos. PO/PM o admin en los dos proyectos; la versión no puede existir en el destino y una release con ciclo de prueba no se mueve. MCP: move_release.
  • PUT /releases/{id}/notes (tracker:write): guarda las notas de la versión, el texto para el cliente que la pantalla copia y envía por correo: {"release_notes": "# App 2.7.0\n\n## Novedades\n\n- Ahora se puede..."}. Markdown simple (# título, ## sección, - elemento; sin negrita ni enlaces). Reemplaza el texto entero; vacío o null vuelve al borrador generado de las issues resueltas. PO/PM o admin. La respuesta trae release_notes y release_notes_saved. No envía el correo.
  • GET /test-cases (tracker:read): casos de prueba activos. Query: project, q (parte del código o del título) e include_archived.
  • POST /test-cases (tracker:write): crea un caso, {"project": "MOB", "title": "...", "module": "...", "priority": "high", "steps": [{"action": "...", "expected": "..."}]}. QA o admin. El código (TC-MOB-0001) se genera.
  • GET /test-cycles (tracker:read): los ciclos más recientes con el avance. Query: project y status.
  • GET /test-cycles/{id} (tracker:read): el ciclo con cada caso y el resultado (pass, fail, blocked, in_progress, not_started), el comentario, quién probó y la issue abierta a partir del fail.
  • POST /test-cycles (tracker:write): crea un ciclo, {"project": "MOB", "name": "Regresión 2.7.0", "release": "2.7.0", "environment": "...", "cases": ["TC-MOB-0001"]}. Sin cases, entran todos los casos activos del proyecto. QA o admin.
  • POST /test-cycles/{id}/results (tracker:write): resultados del CI, hasta 200 por pedido, {"results": [{"test_case": "TC-MOB-0001", "status": "fail", "comment": "...", "open_issue": true}]}. status: pass, fail, blocked o in_progress; comentario obligatorio para fail y blocked. Con open_issue, el fail abre la issue ya completada con el caso (o devuelve la que ya existe); si la issue no se abre, el resultado queda guardado y el elemento vuelve con warning. Elemento por elemento, con recorded, failed y results. QA o admin.
  • POST /test-cycles/{id}/status (tracker:write): {"action": "start" | "finish" | "cancel" | "reopen"}. Un ciclo cerrado no acepta resultados hasta que se reabre.