How To Build a CI/CD Testing Pipeline in 30 Minutes

If you’ve ever shipped a “tiny” frontend change that silently broke checkout or login, you already know why CI/CD testing pipelines matter: they turn unknown risk into fast feedback on every PR.

This guide shows a practical, minimal pipeline you can set up in ~30 minutes: run BugBug end-to-end (E2E) tests in the cloud on every pull request, block merges when tests fail, and keep results visible to the whole team—without standing up Selenium grid infrastructure or babysitting flaky runners.

What you’re building in 30 minutes

A CI/CD testing pipeline that:

• Triggers on pull requests (and optionally on merges to main)
• Runs a smoke suite first (fast signal)
• Optionally runs a full regression suite on merges / nightly
• Reports pass/fail back to your CI and keeps run details in BugBug Cloud

BugBug supports running tests and suites in CI/CD via official GitHub Action, CLI, or public API.

Prerequisites

You need:

1. A BugBug workspace/project with at least:
   • 1 smoke suite (3–10 critical flows)
   • 1 regression suite (optional for later)
2. A BugBug API token (you’ll store it as a CI secret). BugBug’s docs point you to the API token and Swagger docs.
3. Your app deployed somewhere the CI can reach (staging preview URL, ephemeral environment, or a stable staging).

Step 1 (5 minutes): Create a tiny “smoke suite” in BugBug

A good smoke suite is small and stable:

• Login (or magic link / SSO entry)
• One “money” path (checkout, lead form submit, upgrade)
• One core CRUD flow (create/edit item)
• A permissions guardrail (unauthorized user can’t access X)

BugBug is built for fast E2E creation and cloud execution. The key here is repeatability: make the test data deterministic (seed users, reset state, or use isolated test accounts).

Step 2 (5 minutes): Decide how CI will run BugBug tests

You have three common options:

Option A: GitHub Action (fastest for GitHub repos)

BugBug provides an official GitHub Action and recommends it for GitHub integration.

Important: the Marketplace page notes the Action is available only for paid plans.

Option B: BugBug CLI (works anywhere)

BugBug documents running tests from terminal via an npm CLI.

Option C: Public API (most flexible)

If you want custom orchestration (dynamic suite selection, advanced reporting), BugBug supports running via API.

For “30 minutes,” pick A if you’re on GitHub + eligible plan; otherwise B is the most universal.

Step 3 (10 minutes): Wire it into GitHub Actions

3A) Store secrets in GitHub

In your repo:

• Settings → Secrets and variables → Actions
• Add:
  • BUGBUG_TOKEN (your BugBug API token)
  • BUGBUG_PROJECT_ID (if required by your chosen run mode)
  • Optional: BASE_URL (your staging/preview URL)

3B) Create a workflow file

Variant 1: Using BugBug Cloud Runner (official Action)

name: E2E Smoke (BugBug)



on:

  pull_request:



jobs:

  e2e-smoke:

    runs-on: ubuntu-latest

    steps:

      - name: Run BugBug smoke suite in cloud

        uses: bugbug-io/bugbug-github-action@v1

        with:

          token: ${{ secrets.BUGBUG_TOKEN }}

          suiteId: ${{ secrets.BUGBUG_SMOKE_SUITE_ID }}

          # baseUrl: ${{ secrets.BASE_URL }}   # if supported / needed

Variant 2: Using BugBug CLI (portable, works across CI systems)

BugBug documents running tests from terminal and provides commands via the UI (“Run via CLI”) for test IDs.

name: E2E Smoke (BugBug CLI)



on:

  pull_request:



jobs:

  e2e-smoke:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v4



      - uses: actions/setup-node@v4

        with:

          node-version: 20



      - name: Install BugBug CLI

        run: npm i -g bugbug



      - name: Run smoke suite

        env:

          BUGBUG_TOKEN: ${{ secrets.BUGBUG_TOKEN }}

        run: |

          # Example pattern; copy the exact command from BugBug UI ("Run via CLI")

          bugbug run suite ${{ secrets.BUGBUG_SMOKE_SUITE_ID }}

If you’re new to structuring test steps in GitHub Actions, GitHub’s own learning path is a solid reference for the basics. GitHub Resources

Step 4 (5 minutes): Make it CI/CD-friendly (less flaky, more signal)

A pipeline is only as good as the trust people place in it. The fastest way to destroy trust is flaky tests that block merges “randomly.”

Here’s the short list that usually fixes 80% of pipeline pain:

Use stable, pipeline-safe test data

• One account per environment (e2e_user+staging@…)
• Reset state before the test (API reset endpoint, DB seed, or admin UI)
• Avoid dependencies on email/SMS unless you control the inbox/provider

Add explicit waits for conditions, not time

If your app is async, waiting for “element visible” beats sleep(2000) every time.

Separate smoke vs regression

• Smoke on every PR
• Regression on merges to main or nightly

This prevents PR checks from becoming a 45-minute tax.

Step 5 (5 minutes): Expand to GitLab CI/CD (optional template)

If your team is on GitLab, the same “CLI in a job” approach works. GitLab publishes CI/CD examples and docs that map directly to this pattern.

stages:

  - test



e2e_smoke:

  stage: test

  image: node:20

  script:

    - npm i -g bugbug

    - bugbug run suite $BUGBUG_SMOKE_SUITE_ID

  variables:

    BUGBUG_TOKEN: $BUGBUG_TOKEN

  only:

    - merge_requests

Store BUGBUG\_TOKEN and BUGBUG\_SMOKE\_SUITE\_ID as protected CI variables in GitLab.

What “done” looks like

You’re finished when:

• A PR triggers a CI run automatically
• BugBug smoke suite runs in the cloud
• CI shows ✅ / ❌ and blocks merges on failure
• The team can click into BugBug results to debug quickly

Common upgrades after day 1

Once the pipeline is stable, these give real ROI:

1. Parallel suites: split regression into logical chunks (auth, billing, admin).
2. Fail-fast smoke: smoke first, regression second.
3. Notifications: pipe failures to Slack (BugBug lists Slack among integrations).

Nightly full regression: catch slow-burn issues without punishing PR velocity.