Servicio de almacenamiento autohospedado Allure 3

Allure Report Storage es un servicio gratuito y de código abierto (Apache-2.0) que permite a Allure 3 publicar reportes HTML y conservar el historial entre ejecuciones, sin depender de alojamiento externo. Lo ejecutas tú mismo — como un contenedor Docker o un Cloudflare Worker — y Allure 3 se comunica con él mediante el cliente integrado allureService.

Con allureService.accessToken configurado y publish: true en los plugin(s) relevantes, la publicación es automática: cada reporte se sube, obtiene una URL para compartir y pasa a formar parte del historial de ese proyecto.

Cómo funciona

Los reportes se organizan por repositorio y rama en lugar de un ID de proyecto fijo, así que el historial se delimita por rama de forma predeterminada. Allure 3 detecta automáticamente repo y branch: a partir de variables de entorno proporcionadas por el CI en un servidor CI compatible, o bien desde el nombre del repositorio git actual y la rama que está activa.

Cada publicación:

1. crea un reporte borrador para ese repo/branch;
2. sube los archivos generados del reporte;
3. marca el reporte como completo y adjunta un punto de historial.

Un reporte completado es inmutable: solo puede eliminarse, no modificarse. El punto de historial es lo que habilita el Historial y reintentos entre ejecuciones separadas.

Despliegue

Ejecuta el servicio siguiendo la guía de Docker o la guía de Cloudflare Worker. Ambas cubren la configuración completa paso a paso. Ninguna requiere una base de datos externa ni un bucket por defecto: Docker utiliza una base de datos SQLite incluida y disco local, el Worker usa Cloudflare D1 y R2.

El lugar donde se almacenan los archivos de reporte es independiente de dónde se ejecuta el servicio:

• Sistema de archivos local — predeterminado para Docker/Node; los archivos se guardan en el directorio de datos configurado.
• Cualquier bucket compatible con S3 — AWS S3, el endpoint compatible con S3 de R2, u otro proveedor como MinIO. Consulta la guía de Docker para la configuración.
• Cloudflare R2 — se utiliza automáticamente mediante una vinculación nativa al ejecutarse como Worker.

Conectar Allure 3 al servicio de almacenamiento

Genera un token de acceso al reporte usando el ACCESS_TOKEN de bootstrap configurado durante el despliegue:

curl -sS -X POST http://localhost:3000/api/token \
  -H "Authorization: Bearer storage_bootstrap_token"

Esto devuelve un token en el formato ars1.<payload>.<signature>. A diferencia del token de bootstrap, es seguro entregarlo al CI: solo autoriza la publicación y la lectura del historial. Además, es autodocumentado: el payload incluye la URL de la instancia de almacenamiento, así que Allure 3 no necesita una configuración separada de dirección del servidor.

Agrégalo a la configuración de Allure 3, junto con publish: true en los plugin(s) que se van a publicar:

import { defineConfig } from "allure";

export default defineConfig({
  name: "Allure Report",
  plugins: {
    awesome: {
      options: {
        publish: true, // especifica explícitamente qué reportes deben publicarse
      },
    },
  },
  allureService: {
    accessToken: "ars1...",
  },
});

A partir de aquí, ejecutar pruebas a través de Allure 3 publica el reporte automáticamente.

Elegir una rama principal

La rama principal de un repositorio es main por defecto. Si la tuya tiene otro nombre, configúralo explícitamente (también usando el token de bootstrap) para que las demás ramas se comparen contra la base correcta:

curl -sS -X POST http://localhost:3000/api/projects/main-branch \
  -H "Authorization: Bearer storage_bootstrap_token" \
  -H "Content-Type: application/json" \
  -d '{ "repo": "repo_name", "main_branch": "main_branch_name"}'

Profundidad de historial y ramas

Cada punto de historial de un reporte completado se conserva permanentemente: nada expira automáticamente, solo la eliminación explícita lo borra. Allure 3 obtiene los 10 puntos más recientes por rama de forma predeterminada; configura historyLimit para consultar más atrás:

export default defineConfig({
  historyLimit: 50,
});

A diferencia de historyPath (que elimina entradas antiguas de un archivo local), historyLimit aquí solo limita lo que se consulta: el historial completo permanece almacenado. Las dos opciones también son mutuamente excluyentes: historyPath se ignora si se configura allureService.accessToken.

El historial de una rama que no es principal se rellena con reportes antiguos de la rama principal cuando no tiene suficientes propios para completar la cantidad solicitada, extendiendo su propia línea de tiempo hacia atrás, pero nunca mezclados. Así, una rama con una o dos publicaciones aún obtiene una gráfica de tendencias poblada. El historial de la rama principal nunca se rellena, y una rama con suficientes reportes propios tampoco. Esto se basa en el nombre de la rama, no en la ascendencia git: una rama huérfana de git se trata igual que una rama de feature real. Solo GET /api/history (y por tanto las gráficas de tendencias y la pestaña de historial) realiza este mezclado; la página de árbol de reportes siempre agrupa estrictamente por rama.

Navegar reportes publicados

Cada instancia también sirve una página que lista los reportes completados de un repositorio, agrupados por rama:

https://<tu-dominio-de-almacenamiento>/reports/tree?repo=<repo>

Útil para encontrar un reporte anterior sin buscar en los registros del CI.

Eliminar un reporte

Un reporte completado solo puede eliminarse, no editarse: esto borra tanto sus archivos como su punto de historial, autenticado con un token de acceso al reporte en lugar del token de bootstrap:

curl -sS -X POST http://localhost:3000/api/report/<report-uuid>/delete \
  -H "Authorization: Bearer ars1..."

Después, la URL del reporte deja de funcionar y desaparece de GET /api/history y de la página de árbol. Si era uno de los reportes de la rama principal, las ramas que se rellenaban con él recurren a lo que quede disponible.