Quality Gate Allure 3

Quality Gate es una característica integrada de Allure Report 3 que te permite aplicar un estándar de calidad en tu proyecto, típicamente cuando está a punto de avanzar de una etapa de despliegue a otra. Esta característica falla una ejecución de prueba si viola el conjunto de reglas definido, evitando así el despliegue de un proyecto que no cumple con el estándar de calidad deseado.

Allure Report tiene estas reglas incorporadas:

Nombre de regla	Descripción de regla	Nombre de función de regla	Unidades
maxFailures	Número máximo permitido de pruebas fallidas y rotas	maxFailuresRule	Número de pruebas
minTestsCount	Número mínimo requerido de pruebas ejecutadas	minTestsCountRule	Número de pruebas
successRate	Tasa de éxito mínima requerida: pruebas aprobadas divididas entre pruebas aprobadas, fallidas y rotas (las pruebas omitidas y desconocidas se excluyen)	successRateRule	Ratio (0.0 a 1.0)
newTests	Si es true, la ejecución debe contener al menos una prueba nueva, es decir, una prueba que no esté en el historial	newTestsRule	Booleano
maxDuration	Duración máxima permitida para cualquier prueba individual	maxDurationRule	Milisegundos
allTestsContainEnv	Todas las pruebas deben pertenecer al entorno especificado	allTestsContainEnvRule	ID de entorno (string)
environmentsTested	Cada entorno especificado debe tener al menos una prueba en la ejecución	environmentsTestedRule	Array de IDs de entorno
metricMax	Valor promedio máximo permitido de una métrica de rendimiento	metricMaxRule	Objeto, ver Reglas de métrica
metricMin	Valor promedio mínimo requerido de una métrica de rendimiento	metricMinRule	Objeto, ver Reglas de métrica
metricMaxDelta	Cambio máximo permitido de una métrica de rendimiento desde la ejecución anterior	metricMaxDeltaRule	Objeto, ver Reglas de métrica
metricMaxDeltaPercent	Cambio máximo permitido de una métrica de rendimiento desde la ejecución anterior, en porcentaje	metricMaxDeltaPercentRule	Objeto, ver Reglas de métrica

Las reglas newTests, metricMaxDelta y metricMaxDeltaPercent comparan la ejecución con ejecuciones anteriores, por lo que requieren historial: ya sea un archivo de historial establecido con historyPath, o Allure Report Storage. Sin historial, ninguna prueba se considera nueva.

Todas las reglas ignoran los intentos anteriores de pruebas reintentadas (solo cuenta el último intento) y los fallos marcados como Silenciado o Aceptado con resoluciones. Los fallos vinculados a una resolución de Issue se siguen contando.

También puedes usar reglas de terceros y escribir reglas completamente personalizadas tú mismo.

Configuración Básica

Reglas Incorporadas

Como otras características avanzadas, puedes configurar Quality Gate en el archivo de configuración de tiempo de ejecución.

Dependiendo del formato, agrega estas líneas a él:

allurerc.mjs

import { defineConfig } from "allure";

export default defineConfig({
  qualityGate: {
    rules: [
      {
        <nombre-de-regla>: <valor-esperado>,
      },
    ],
 },
})

allurerc.json

{
  "qualityGate": {
    "rules": [
      {
        "<nombre-de-regla>": "<valor-esperado>"
      }
    ]
  }
}

allurerc.yaml

qualityGate:
  rules:
    - <nombre-de-regla>: <valor-esperado>

¿Qué formato de configuración usar?

Generalmente, si solo usas las reglas incorporadas sin ninguna lógica adicional aplicada, puedes apegarte a archivos de configuración estáticos .json o .yaml. Si quieres personalizar cualquier cosa, aplicar filtros adicionales a los resultados de prueba analizados, o usar cualquier regla personalizada, necesitas la configuración dinámica .mjs o .js, ya que estarás agregando código ejecutable a ella.

Por ejemplo:

import { defineConfig } from "allure";

export default defineConfig({
  qualityGate: {
    rules: [
      {
        maxFailures: 5,
        minTestsCount: 30,
        // código ejecutable que valida solo resultados de prueba con etiqueta de severidad crítica
        filter: (tr) =>
          tr.labels.some((label) => label.name === "severity" && label.value === "critical"),
      },
    ],
  },
});

Si cualquiera de las reglas maxFailures y minTestsCount que configuraste aquí fallan, tu ejecución se completará con código de salida 1, y Quality Gate imprimirá un mensaje en la consola reportando qué regla falló.

Si ninguna regla de Quality Gate falla, el código de salida será 0. Cuando Quality Gate está configurado, determina el código de salida de allure run: si algunas pruebas fallan, pero su número se mantiene dentro de los límites que estableciste, el código de salida sigue siendo 0. El reporte muestra tanto el código de salida real como el código de salida original del proceso de prueba (ver Código de salida global).

La pestaña Quality Gates del reporte lista los resultados de todas las reglas, tanto fallidas como aprobadas. Para una regla que depende de pruebas específicas, como maxFailures, expande Resultados de prueba relacionados para ver estas pruebas.

Fast Fail

Si quieres terminar la ejecución de prueba inmediatamente cuando al menos una regla de Quality Gate falla – agrega la propiedad fastFail al conjunto de reglas:

import { defineConfig } from "allure";

export default defineConfig({
  qualityGate: {
    rules: [
      {
        maxFailures: 5,
        fastFail: true,
      },
    ],
  },
});

No todas las reglas tienen sentido con fastFail. No recomendamos habilitar fastFail en conjuntos de reglas que incluyen reglas como minTestsCount y successRate, porque los valores que verifican solo pueden calcularse correctamente después de que se reciban todos los resultados de las pruebas, es decir, después de que la ejecución de pruebas ya haya terminado. Si deseas usar estas reglas, recomendamos moverlas a un nuevo conjunto de reglas (ver abajo) con fastFail establecido en false.

Múltiples Conjuntos de Reglas

También puedes definir múltiples conjuntos de reglas de Quality Gate. Esto puede ser útil cuando quieres separar las reglas de fallo rápido de todas las demás:

import { defineConfig } from "allure";

export default defineConfig({
  qualityGate: {
    rules: [
      {
        // usa el campo id para hacer las reglas del conjunto más fáciles de identificar
        id: "fast-failing ruleset",
        maxFailures: 5,
        fastFail: true,
      },
      {
        id: "non-fast-failing ruleset",
        successRate: 0.95,
      },
    ],
  },
});

Reglas de Métrica

Las reglas metricMax, metricMin, metricMaxDelta y metricMaxDeltaPercent verifican las métricas de rendimiento recolectadas durante la ejecución. Cada una de ellas toma un objeto con la key de la métrica y el límite value:

import { defineConfig } from "allure";

export default defineConfig({
  historyPath: "./history.jsonl",
  qualityGate: {
    rules: [
      {
        // el tiempo promedio de carga de página no debe exceder 1500
        metricMax: { key: "page.load", value: 1500 },
        // el rendimiento promedio de la API debe ser al menos 100
        metricMin: { key: "api.rps", value: 100 },
        // el tiempo promedio de carga de página no debe crecer más de 200 desde la ejecución anterior
        metricMaxDelta: { key: "page.load", value: 200 },
        // el rendimiento promedio de la API no debe caer más de 10% desde la ejecución anterior
        metricMaxDeltaPercent: { key: "api.rps", value: 10 },
      },
    ],
  },
});

• Todas las reglas de métrica verifican el valor promedio de todas las mediciones con la clave dada en la ejecución actual.
• Una regla de métrica falla si la ejecución no tiene mediciones con la clave dada.
• metricMaxDelta y metricMaxDeltaPercent comparan el promedio actual con el valor guardado en el historial de la ejecución anterior, por lo que requieren historial: ya sea un archivo de historial establecido con historyPath, o Allure Report Storage. Si no hay un valor anterior, la regla pasa. Con Allure Report Storage, los primeros reportes de una rama nueva se comparan con la rama principal, y los reportes de un pipeline de pull request se comparan con su rama destino (ver Métricas de rendimiento).
• Si la métrica tiene la configuración better en la configuración de performance, las reglas delta solo fallan ante cambios para peor: un aumento para better: "lower", una disminución para better: "higher". Sin ella, un cambio en cualquier dirección cuenta.

Ejecutar Allure con Quality Gates Habilitados

Hay tres comandos CLI de Allure que aplican quality gates:

• allure run - aplica los quality gates marcados con fastFail a medida que avanza la ejecución de pruebas y verifica si debe terminarse anticipadamente; una vez que la ejecución de pruebas finaliza, aplica todos los quality gates a los resultados de prueba finales.
• allure generate - aplica todos los quality gates a los resultados de prueba que lee. Genera primero el reporte (o escribe el archivo de volcado, si dump está configurado), y luego termina con código de salida 1 si alguna regla falló.
• allure quality-gate - aplica los quality gates contra todos los resultados de prueba de todos los directorios coincidentes. No genera reportes.

allure run y allure generate siempre usan las reglas especificadas en el archivo de configuración.

TIP

Los conjuntos de reglas fastFail solo pueden detener la ejecución de prueba anticipadamente si la integración de Allure escribe cada resultado de prueba tan pronto como la prueba termina. Algunas integraciones escriben todos los resultados al final de la ejecución; en ese caso, las reglas se aplican cuando la ejecución de prueba finaliza.

allure quality-gate usa la configuración por defecto, pero también permite definir las reglas a través del CLI usando estas opciones:

• --max-failures
• --min-tests-count
• --success-rate

Si se usa cualquiera de estas, el archivo de configuración es ignorado y las reglas del comando CLI se usan en su lugar.

También puedes asignar un entorno a todos los resultados de prueba verificados por el comando, de la misma manera que con allure run. Esto afecta a las reglas relacionadas con el entorno, como allTestsContainEnv, y al entorno mostrado en los resultados del quality gate:

• --environment - ID de entorno (la clave del config; solo letras, dígitos, guiones bajos y guiones)
• --environment-name - nombre para mostrar del entorno; --environment tiene prioridad si se proporcionan ambos

Por ejemplo:

allure quality-gate --max-failures 5 --environment prod_env
allure quality-gate --max-failures 5 --environment-name "Production"

Reintentos

Los quality gates funcionan con la opción --rerun de allure run, que reinicia el comando de prueba para reintentar las pruebas fallidas:

allure run --rerun 2 -- npm test

El número que pasas es el número total de reinicios disponibles para la ejecución. Cada reinicio usa uno:

• Cuando el comando de prueba termina, Allure lo reinicia con un plan de pruebas que contiene las pruebas fallidas y rotas (excepto las que tienen las resoluciones Silenciado o Aceptado resoluciones) y las pruebas relacionadas con reglas de quality gate fallidas. El plan de pruebas se pasa a través de la variable de entorno ALLURE_TESTPLAN_PATH, por lo que la integración de Allure debe soportar planes de prueba.
• Cuando un conjunto de reglas fastFail detiene el comando de prueba anticipadamente, los resultados están incompletos, por lo que Allure reinicia el comando de prueba completo.

Los quality gates se aplican al último intento de cada prueba. Con --rerun 0, o sin --rerun, un conjunto de reglas fastFail detiene la ejecución sin reiniciarla.

Builds Multi-Entorno

Si ejecutas pruebas en varios entornos y construyes un solo reporte a partir de archivos de volcado, puedes aplicar quality gates en cualquiera de las etapas, o en ambas:

• En cada entorno. Agrega qualityGate a la configuración usada para la ejecución de prueba en cada entorno. Cada ejecución verifica sus propios resultados de prueba y falla si violan las reglas. Los resultados se guardan en el archivo de volcado, y el reporte final los muestra por entorno. Si la configuración usada para construir el reporte final no tiene qualityGate, las reglas no se aplican de nuevo.
• En el reporte final. Agrega qualityGate a la configuración usada para construir el reporte final con allure generate --dump .... Las reglas se aplican a los resultados de prueba combinados de todos los entornos. Usa esto si necesitas una sola decisión de aprobado/fallido para toda la build, por ejemplo, para la verificación de Quality Gate de la GitHub Action, que lee el archivo quality-gate.json generado con el reporte final.

Por ejemplo, con un archivo de configuración que aplica quality gates cuando la variable de entorno ALLURE_QUALITY_GATE está establecida:

import { defineConfig } from "allure";

export default defineConfig({
  ...(process.env.ALLURE_QUALITY_GATE ? { qualityGate: { rules: [{ maxFailures: 0 }] } } : {}),
});

Cada entorno luego ejecuta las pruebas sin el quality gate:

allure run --environment=linux --dump=allure-results-linux -- npm test

El job final aplica el quality gate a los resultados combinados:

ALLURE_QUALITY_GATE=1 allure generate --dump "allure-results-*.zip"

Ver Resultados de Quality Gate

Los resultados de quality gate están disponibles en varios lugares:

• Terminal. allure run, allure generate y allure quality-gate imprimen las reglas fallidas en la consola.
• Reporte. La pestaña Quality Gates del reporte muestra todas las reglas, tanto fallidas como aprobadas (ver Reglas Incorporadas).
• allure log. El comando allure log imprime las reglas fallidas después de los resultados de prueba. Agrega --all-quality-gate-results para imprimir también las reglas aprobadas, o --no-quality-gate-results para ocultar los resultados de quality gate. Cuando usas el plugin Log en el archivo de configuración, usa sus opciones qualityGateResults y qualityGateFilter en su lugar.
• quality-gate.json. El archivo quality-gate.json en el directorio del reporte contiene los resultados de todas las reglas en formato JSON. Para cada regla, lista los IDs de los resultados de prueba relacionados; los detalles de estos resultados de prueba están en el archivo test-results.json en el mismo directorio. Las integraciones de CI, como la GitHub Action, usan estos archivos para reportar el estado del quality gate.

Configuración Avanzada

Las características en esta sección requieren archivos de configuración dinámicos (.mjs/.js) que pueden ejecutar código JavaScript.

Filtros Personalizados

Puedes aplicar lógica de filtrado personalizada a los resultados de prueba que Quality Gate analiza.

El segundo conjunto de reglas en el ejemplo a continuación valida solo resultados de prueba con etiqueta de severidad crítica: si alguna prueba de este tipo falla, toda la ejecución falla inmediatamente, porque fastFail está establecido en true para este conjunto de reglas.

import { defineConfig } from "allure";

export default defineConfig({
  qualityGate: {
    rules: [
      // el primer conjunto de reglas permite tener hasta 10 pruebas fallidas en total, no fallará en tiempo de ejecución y reportará el resultado de validación al final
      {
        id: "first-set",
        maxFailures: 10,
      },
      // el segundo conjunto de reglas falla inmediatamente si hay al menos un fallo de prueba crítico
      {
        id: "second-set",
        maxFailures: 0,
        fastFail: true,
        // valida solo resultados de prueba con etiqueta de severidad crítica
        filter: (tr) =>
          tr.labels.some((label) => label.name === "severity" && label.value === "critical"),
      },
    ],
  },
});

Campo use

El arreglo use en la configuración de Allure 3 es una lista de implementaciones de reglas, donde cada implementación es un objeto que define cómo funciona una regla específica.

La lista predeterminada incluye las implementaciones de todas las reglas incorporadas, por lo que si solo las estás usando, como en los ejemplos de la sección Configuración Básica, puedes omitirlo.

Pero cuando necesites introducir una regla personalizada o modificar una existente, debes proporcionar tu propia lista, y esta lista debe incluir las implementaciones de todas las reglas mencionadas en tus conjuntos de reglas - tanto predeterminadas como personalizadas.

Debes importar las implementaciones de reglas incorporadas desde allure/rules, y las implementaciones de reglas personalizadas desde los paquetes o archivos que las contengan:

import { defineConfig } from "allure";
import { maxFailuresRule } from "allure/rules";
import { ruleImplementation1, ruleImplementation2 } from "custom-rules";

export default defineConfig({
  qualityGate: {
    rules: [
      {
        maxFailures: 5,
        rule1: 1,
        rule2: 2,
      },
    ],
    use: [
      maxFailuresRule, // implementa maxFailures, que es incorporada, pero aún tienes que listarla, porque también estás usando reglas personalizadas
      ruleImplementation1, // implementa la regla personalizada rule1
      ruleImplementation2, // implementa la regla personalizada rule2
    ],
  },
});

Personalizar el Mensaje de una Regla

Si una regla falla, Allure imprime un mensaje en la consola. Puedes personalizar este mensaje a tu gusto redefiniendo la función message en el arreglo use de la configuración de Quality Gate.

import { defineConfig } from "allure";
import { maxFailuresRule } from "allure/rules";

export default defineConfig({
  qualityGate: {
    rules: [
      {
        maxFailures: 5,
      },
    ],
    use: [
      {
        // no olvides usar el operador rest spread para mantener intactos los demás campos de la regla
        ...maxFailuresRule,
        message: ({ expected, actual }) =>
          `Mensaje personalizado: esperado ${expected}, obtenido ${actual}`,
      },
    ],
  },
});

Usar Reglas Externas

Puedes usar reglas de Quality Gate de terceros:

• instala el paquete con la regla en tu proyecto
• importa las reglas del paquete
• proporciónalas al campo use en la configuración de quality gate:

import { defineConfig } from "allure";
import { rule1, rule2 } from "custom-rules-package";

export default defineConfig({
  qualityGate: {
    rules: [
      // define conjuntos de reglas según la firma de las reglas externas
    ],
    use: [rule1, rule2],
  },
});

TIP

Si quieres usar reglas predeterminadas y externas juntas, asegúrate de importar las reglas predeterminadas del paquete allure/rules e incluirlas en el arreglo use también:

import { defineConfig } from "allure";
// importa reglas predeterminadas de una vez
import { qualityGateDefaultRules } from "allure/rules";
// o impórtalas por separado
import {
  allTestsContainEnvRule,
  environmentsTestedRule,
  maxDurationRule,
  maxFailuresRule,
  minTestsCountRule,
  successRateRule,
} from "allure/rules";
import { rule1, rule2 } from "custom-rules-package";

export default defineConfig({
  qualityGate: {
    rules: [
      // define conjuntos de reglas según la firma de las reglas externas
    ],
    use: [...qualityGateDefaultRules, rule1, rule2],
  },
});

Si no reasignas el campo use, Allure usará solo las reglas predeterminadas automáticamente sin importaciones adicionales.

Crear Reglas Personalizadas

Puedes crear tus propias reglas de quality gate implementando la interfaz QualityGateRule<T,K=T>, donde T es el tipo del valor que la regla está verificando, y K es el tipo del resultado intermedio que la regla está usando para mantener el estado entre los lotes de resultados de pruebas que procesa.

WARNING

Si estás usando TypeScript, ¡asegúrate de compilar tu archivo de regla personalizada antes de usarlo! Allure no soporta la compilación de TypeScript al vuelo.

Esta es una versión simplificada de la regla incorporada maxFailures:

TypeScript

import { filterUnsuccessful } from "@allurereport/core-api";
import { type QualityGateRule } from "@allurereport/plugin-api";

export const maxFailuresRule: QualityGateRule<number> = {
  rule: "maxFailures",
  message: ({ actual, expected }) =>
    `The number of failed tests ${String(actual)} exceeds the allowed threshold value ${String(expected)}`,
  successMessage: ({ actual, expected }) =>
    `The number of failed tests ${String(actual)} is within the allowed threshold value ${String(expected)}`,
  validate: async ({ trs, expected, state }) => {
    const previous = Number(state.getResult() ?? 0);
    const failedTrs = trs.filter(filterUnsuccessful);
    const testResults = failedTrs.map((tr) => tr.id);
    const actual = previous + failedTrs.length;

    state.setResult(actual, testResults);

    return {
      success: actual <= expected,
      actual,
      testResults,
    };
  },
};

JavaScript

import { filterUnsuccessful } from "@allurereport/core-api";

export const maxFailuresRule = {
  rule: "maxFailures",
  message: ({ actual, expected }) =>
    `The number of failed tests ${String(actual)} exceeds the allowed threshold value ${String(expected)}`,
  successMessage: ({ actual, expected }) =>
    `The number of failed tests ${String(actual)} is within the allowed threshold value ${String(expected)}`,
  validate: async ({ trs, expected, state }) => {
    const previous = state.getResult() ?? 0;
    const failedTrs = trs.filter(filterUnsuccessful);
    const testResults = failedTrs.map((tr) => tr.id);
    const actual = previous + failedTrs.length;

    state.setResult(actual, testResults);

    return {
      success: actual <= expected,
      actual,
      testResults,
    };
  },
};

El objeto de regla contiene los siguientes campos:

rule – el nombre de la regla que se usa para identificar la regla en el archivo de configuración; también se usa en los mensajes de validación impresos en la consola y mostrados en el reporte

message – función que formatea el mensaje mostrado si la regla falla; puede ser redefinida en el archivo de configuración:

• recibe un objeto con los siguientes campos:
  • actual: el valor real calculado por la función validate.
  • expected: el valor esperado configurado en el conjunto de reglas.
• debe retornar una cadena de texto para mostrar.

successMessage (opcional) – función que formatea el mensaje mostrado si la regla pasa. Recibe los mismos argumentos que message. Si se omite, Allure usa un mensaje genérico con los valores real y esperado.

validate – función de validación que implementa la lógica de validación:

• recibe un objeto con los siguientes campos:

  • trs: un arreglo de resultados de prueba. Estos pueden ser todos los resultados de prueba producidos en la ejecución o solo una porción de ellos, es decir, un lote. Los intentos anteriores de pruebas reintentadas y los fallos con las resoluciones Silenciado o Aceptado resoluciones ya están excluidos.
  • expected: el valor esperado de tipo T configurado en el conjunto de reglas.
  • state: un objeto que mantiene el estado a través de múltiples llamadas a validate contra diferentes lotes de resultados de prueba. Ver un ejemplo más abajo.
  • environment: el ID del entorno al que se aplican las reglas, si corresponde.
  • metrics: un arreglo de las métricas de rendimiento recolectadas en la ejecución.
  • previousHistory: un arreglo de los valores de métrica guardados en el archivo de historial de ejecuciones anteriores.

• debe retornar una promesa que se resuelve a un objeto con los siguientes campos:

  • success: el resultado de la validación (true o false).
  • actual: el valor calculado que la regla ha verificado.
  • testResults: un arreglo de IDs de los resultados de prueba relacionados con la regla, por ejemplo, las pruebas fallidas contadas por maxFailures. El reporte lista estas pruebas bajo Resultados de prueba relacionados. Retorna un arreglo vacío si la regla no depende de pruebas específicas.

Para crear una regla personalizada, define un objeto con la estructura descrita anteriormente.

state y Lógica de Fast Fail

Allure Report aplica las reglas de quality gate de dos maneras diferentes:

• cuando la ejecución de pruebas se completa sin activar fast fail, y todos los resultados de prueba están listos: Allure simplemente aplica todas las reglas de quality gate al conjunto completo de resultados.

• mientras la ejecución de pruebas está en progreso: Allure recibe lotes de resultados de prueba del framework de pruebas a medida que avanza sobre las pruebas y los verifica contra las reglas de quality gate de los conjuntos fastFail. Si se viola una regla de un conjunto fastFail, Allure termina la ejecución de pruebas y agrega datos de diagnóstico al reporte.

Algunas reglas funcionan de la misma manera en ambos contextos. Por ejemplo, puedes definir una regla que verifique que todos los bloqueadores pasen: tal regla evalúa los resultados de prueba uno por uno y está bien definida contra cualquier subconjunto de los resultados de prueba.

Otras reglas, por otro lado, dependen de algún estado que debe persistir a través de los lotes de resultados de prueba. La regla incorporada maxFailures mostrada arriba es un buen ejemplo: con fastFail habilitado debe contar las pruebas fallidas a medida que aparecen durante toda la duración de la ejecución.

Tales reglas deben usar el objeto state que se pasa a la función validate. Su método getResult() retorna el valor guardado por la llamada anterior, y setResult(value, testResults) guarda el nuevo valor junto con los IDs de los resultados de prueba relacionados:

import type { QualityGateRule } from "allure/rules";

export const myRule: QualityGateRule<number> = {
  rule: "myRule",
  message: ({ expected, actual }) =>
    `La regla personalizada ha fallado. Esperado: ${expected} no es igual a ${actual}`,
  validate: async ({ trs, expected, state }) => {
    // no hay valor inicial en el estado, así que usamos 0 como respaldo
    const previous = Number(state.getResult() ?? 0);
    const actual = previous + trs.length;

    state.setResult(actual, []);

    return {
      success: actual === expected,
      actual,
      testResults: [],
    };
  },
};

Importar y Habilitar Regla Personalizada

Importa la regla al archivo de configuración, agrégala a la lista use, junto con otras reglas que también quieras usar:

import { defineConfig } from "allure";
import { maxFailuresRule } from "allure/rules";
import { myRule } from "./myRule.js";

export default defineConfig({
  qualityGate: {
    rules: [
      {
        maxFailures: 5,
        myRule: 10,
      },
    ],
    use: [maxFailuresRule, myRule],
  },
});

Generalmente puedes colocar el código de tu regla personalizada en cualquier lugar de tu proyecto siempre que Node pueda resolverlo exitosamente.

Código Fuente de Reglas Incorporadas

Puedes encontrarlo en este repositorio.

Usar Variables de Entorno en Reglas

Si necesitas pasar el valor esperado de una regla desde el exterior (por ejemplo, desde una definición de flujo de trabajo), puedes usar variables de entorno en archivos de configuración dinámicos:

Allure config

import { defineConfig } from "allure";
import { myRule } from "./myRule.js";

const { MY_RULE_VALUE } = process.env;

export default defineConfig({
  name: "Allure Report 3",
  qualityGate: {
    rules: [
      {
        // usa 100 como valor de respaldo cuando la variable de entorno no está establecida
        myRule: MY_RULE_VALUE ? Number(MY_RULE_VALUE) : 100,
      },
    ],
    use: [myRule],
  },
});

CI

jobs:
  test:
    runs-on: "ubuntu-latest"
    steps:
      # ...

      - run: npx allure run -- npm test
        env:
          MY_RULE_VALUE: 10

      # ...