Proveedores de CI

Cada pipeline de esta página hace dos cosas. Un job de sincronización se ejecuta en la rama principal y envía los escenarios de tus archivos .feature, para que Git tenga los casos antes de que cualquier pull request ejecute sus pruebas. Un job de pruebas instala las dependencias y ejecuta cucumber-js con el reporter.

Guarda el token como secreto llamado PROBARA_API_TOKEN, y define PROBARA_PROJECT con el código de tu proyecto. Para una ejecución que reporta a otro proyecto, define projectId en formatOptions de cucumber.js, o pasa --format-options. Configuración enumera todas las opciones.

El job de pruebas no imprime nada en stdout, porque las líneas del reporter van a stderr. Para conservar la salida de progreso de cucumber-js, indica también una ruta para el reporter, como muestra Dónde va la salida.

GitHub Actions

name: BDD

on:
  push:
    branches: [main]
  pull_request:

jobs:
  sync-gherkin:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    env:
      PROBARA_API_TOKEN: ${{ secrets.PROBARA_API_TOKEN }}
      PROBARA_PROJECT: SHOP
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: 22
      - run: npx @probara/cli sync gherkin "features/**/*.feature"

  test:
    runs-on: ubuntu-latest
    env:
      PROBARA_API_TOKEN: ${{ secrets.PROBARA_API_TOKEN }}
      PROBARA_PROJECT: SHOP
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: 22
      - run: npm ci
      - run: npx cucumber-js --format @probara/cucumber-reporter

El job sync-gherkin se ejecuta solo en la rama principal, así que Git tiene los casos antes de que los pull requests ejecuten sus pruebas.

Jobs en paralelo: una ejecución, cerrada por el job final

En GitHub Actions los jobs de un mismo workflow envían a una misma ejecución: el origen de la ejecución identifica la ejecución del workflow por su repositorio, su id y su intento, y el primer job que envía crea la ejecución. Por defecto, cada job cierra su ejecución al terminar, así que los jobs en paralelo definen PROBARA_CLOSE_RUN: false. Un job final cierra la ejecución con probara run close, que no necesita aquí el ULID: needs hace que espere a todos los jobs de pruebas, y if: always() lo ejecuta aunque fallen.

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        area: [cart, checkout]
    env:
      PROBARA_API_TOKEN: ${{ secrets.PROBARA_API_TOKEN }}
      PROBARA_PROJECT: SHOP
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: 22
      - run: npm ci
      - run: npx cucumber-js --format @probara/cucumber-reporter "features/${{ matrix.area }}/**/*.feature"
        env:
          # A job leaves the run open for the others.
          PROBARA_CLOSE_RUN: false

  probara:
    needs: test
    if: always()
    runs-on: ubuntu-latest
    env:
      PROBARA_API_TOKEN: ${{ secrets.PROBARA_API_TOKEN }}
      PROBARA_PROJECT: SHOP
    steps:
      - uses: actions/setup-node@v5
        with:
          node-version: 22
      - run: npx --yes @probara/cli@0.6 run close

• Un job tras el cierre recibe 409 ci_run_closed: el formateador registra el motivo, no envía nada más, y las pruebas conservan su código de salida (solución de problemas). Mantén cada job que envía en needs.
• Una nueva ejecución del workflow (re-run) es otro intento: envía a una ejecución propia.
• Un solo job no necesita nada de esto: su ejecución se cierra al terminar, como en cualquier otro caso.

GitLab CI

stages:
  - sync
  - test

sync-gherkin:
  stage: sync
  image: node:22
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  variables:
    PROBARA_PROJECT: SHOP
  script:
    - npx @probara/cli sync gherkin "features/**/*.feature"

test:
  stage: test
  image: node:22
  variables:
    PROBARA_PROJECT: SHOP
  script:
    - npm ci
    - npx cucumber-js --format @probara/cucumber-reporter

El job sync-gherkin se ejecuta solo en la rama principal. El reporter lee las mismas claves que escribió la sincronización, así que los resultados de cada rama llegan a los casos de la rama principal.

Jenkins

pipeline {
  agent { docker { image 'node:22' } }
  environment { PROBARA_PROJECT = 'SHOP' }
  stages {
    stage('Sync Gherkin') {
      when { branch 'main' }
      steps {
        withCredentials([string(credentialsId: 'probara-api-token', variable: 'PROBARA_API_TOKEN')]) {
          sh 'npx @probara/cli sync gherkin "features/**/*.feature"'
        }
      }
    }
    stage('Test') {
      steps {
        withCredentials([string(credentialsId: 'probara-api-token', variable: 'PROBARA_API_TOKEN')]) {
          sh 'npm ci'
          sh 'npx cucumber-js --format @probara/cucumber-reporter'
        }
      }
    }
  }
}

Guarda el token como credencial de tipo texto secreto llamada probara-api-token. La etapa Sync Gherkin se ejecuta solo en la rama main.

CircleCI

version: 2.1

jobs:
  sync-gherkin:
    docker:
      - image: cimg/node:22.12
    environment:
      PROBARA_PROJECT: SHOP
    steps:
      - checkout
      - run: npx @probara/cli sync gherkin "features/**/*.feature"

  test:
    docker:
      - image: cimg/node:22.12
    environment:
      PROBARA_PROJECT: SHOP
    steps:
      - checkout
      - run: npm ci
      - run: npx cucumber-js --format @probara/cucumber-reporter

workflows:
  build:
    jobs:
      - sync-gherkin:
          filters:
            branches:
              only: main
      - test

Guarda el token en una variable de entorno del proyecto llamada PROBARA_API_TOKEN. El job sync-gherkin se ejecuta solo en la rama principal.

Azure Pipelines

trigger:
  branches:
    include: [main]

pr:
  branches:
    include: [main]

variables:
  PROBARA_PROJECT: SHOP

stages:
  - stage: Sync
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - job: SyncGherkin
        pool:
          vmImage: ubuntu-latest
        steps:
          - task: NodeTool@0
            inputs:
              versionSpec: '22.x'
          - script: npx @probara/cli sync gherkin "features/**/*.feature"
            env:
              PROBARA_API_TOKEN: $(PROBARA_API_TOKEN)

  - stage: Test
    jobs:
      - job: Cucumber
        pool:
          vmImage: ubuntu-latest
        steps:
          - task: NodeTool@0
            inputs:
              versionSpec: '22.x'
          - script: npm ci
          - script: npx cucumber-js --format @probara/cucumber-reporter
            env:
              PROBARA_API_TOKEN: $(PROBARA_API_TOKEN)

Guarda el token como variable secreta de la pipeline llamada PROBARA_API_TOKEN. La etapa Sync se ejecuta solo en la rama main.

Bitbucket Pipelines

image: node:22

definitions:
  steps:
    - step: &sync-gherkin
        name: Sync Gherkin
        script:
          - npx @probara/cli sync gherkin "features/**/*.feature"

    - step: &cucumber
        name: Cucumber
        script:
          - npm ci
          - npx cucumber-js --format @probara/cucumber-reporter

pipelines:
  default:
    - step: *cucumber
  branches:
    main:
      - step: *sync-gherkin
      - step: *cucumber

Guarda el token como variable del repositorio protegida, llamada PROBARA_API_TOKEN. Define PROBARA_PROJECT como variable del repositorio, o en el environment de cada paso. La rama main sincroniza antes de sus pruebas; las demás ramas solo ejecutan las pruebas.

Buildkite

steps:
  - label: ':probara: Sync Gherkin'
    branches: 'main'
    command: npx @probara/cli sync gherkin "features/**/*.feature"
    env:
      PROBARA_PROJECT: SHOP

  - label: ':cucumber: Tests'
    command:
      - npm ci
      - npx cucumber-js --format @probara/cucumber-reporter
    env:
      PROBARA_PROJECT: SHOP

Guarda el token en los secretos de la pipeline como PROBARA_API_TOKEN, por ejemplo con tu plugin de secretos. El paso de sincronización se ejecuta solo en la rama main. Un command de Buildkite ejecuta cada línea en orden.