Run Vibium Tests in Azure DevOps

To run Vibium tests in Azure DevOps, add an azure-pipelines.yml that installs Chrome's system libraries, runs pip install vibium (or npm install vibium), sets HEADLESS=true, and executes your test command — then publish screenshots and JUnit results as pipeline artifacts. Vibium ships as a single Go binary that auto-downloads Chrome for Testing on first run, so the hosted agent has no driver to install and no browser version to align — the classic cause of red CI in older stacks. On the ubuntu-latest Microsoft-hosted agent you apt-get a handful of shared libraries (libnss3, libgbm1, libasound2), install Vibium, flip the headless flag through a variable, and run pytest or your Node runner. Because Vibium's find() auto-waits for actionability, the suite that passes on your laptop passes on a slower agent without sprinkled sleep() calls. Add a failure-artifact step and a JUnit publish task, and you get a fast, debuggable pipeline on every push and pull request.

What does a Vibium Azure DevOps pipeline look like end to end?

The path from a commit to a green Azure DevOps run is short and linear, because Vibium removes the browser-provisioning stage that dominates most CI setups. Each stage below maps to a section of this guide: install the OS libraries Chrome needs, install Vibium (which fetches its own Chrome), run the suite headless, then publish the results and any failure evidence back to the run.

This is the whole pipeline. There is no "download browser" or "match driver version" box in that diagram, and that omission is the point — it is the single biggest reason Vibium pipelines stay green while driver-based ones drift out of sync. If you are new to the tool, skim what is Vibium first for the mental model, then come back for the Azure DevOps specifics.

What is the minimal azure-pipelines.yml for Vibium?

The smallest working pipeline checks out your code, installs Chrome's libraries and Vibium, and runs the suite headless on the Microsoft-hosted Ubuntu agent. Drop this file at the root of your repository as azure-pipelines.yml and Azure DevOps picks it up automatically.

trigger:
  - main
 
pr:
  - main
 
pool:
  vmImage: ubuntu-latest
 
variables:
  HEADLESS: "true"
 
steps:
  - task: UsePythonVersion@0
    inputs:
      versionSpec: "3.12"
 
  - script: |
      sudo apt-get update
      sudo apt-get install -y \
        libnss3 libatk-bridge2.0-0 libgbm1 libasound2 \
        libxkbcommon0 libxcomposite1 libxdamage1 libxfixes3 \
        libxrandr2 libdrm2 libpango-1.0-0 libcairo2
    displayName: "Install Chrome system libraries"
 
  - script: |
      pip install vibium pytest
      vibium install    # pre-download Chrome for Testing
    displayName: "Install Vibium"
 
  - script: pytest -v
    displayName: "Run Vibium tests"

The trigger and pr blocks run the pipeline on pushes and pull requests targeting main. The HEADLESS: "true" variable is surfaced to your test code as an environment variable so Chrome launches without a display. vibium install pre-fetches Chrome during the job, so the first test does not pay the download cost mid-run.

Why is there no driver or browser install step?

Vibium bundles its WebDriver BiDi engine into one Go binary and downloads a known-good Chrome for Testing itself, so there is nothing to version-match on the agent. In older stacks, Azure DevOps builds broke constantly because the agent's pre-installed browser drifted out of sync with a separately pinned driver — a chromedriver that was correct last week now throws session not created after the image updated Chrome overnight.

Vibium deletes that entire failure class. The only host setup is Chrome's shared system libraries, which you apt-get once, and modern headless Chrome renders with no X server, so you do not need Xvfb or a virtual display. The Microsoft-hosted image already carries most of these libraries; installing them explicitly just makes the pipeline reproducible across image updates. For the architecture behind the single binary, see install Vibium.

How does my code know to run headless in the pipeline?

Read headless mode from an environment variable in your launch code, so the identical suite runs headed on your laptop and headless on the agent. This is the one switch the pipeline flips, and it means there is no separate "CI version" of your tests to fall out of sync.

import os
from vibium import browser_sync as browser
 
headless = os.getenv("HEADLESS", "false") == "true"
vibe = browser.launch(headless=headless)
vibe.go("https://example.com")
print(vibe.find("h1").text())
vibe.quit()

The JavaScript client uses the same trick — process.env.HEADLESS gates the launch option:

const { browser } = require('vibium/sync')
 
const bro = browser.launch({ headless: process.env.HEADLESS === 'true' })
const page = bro.page()
page.go('https://example.com')
console.log(page.find('h1').text())
bro.close()

You debug headed on your machine, push, and the same code runs invisibly on the agent. Centralizing this in a fixture — the pattern in structuring a Vibium suite — keeps every test consistent instead of repeating the getenv dance in each file.

How do I publish test results to the Azure DevOps Tests tab?

Emit a JUnit XML report from your runner and publish it with the PublishTestResults task, and Azure DevOps renders pass/fail trends, durations, and flaky-test history in the Tests tab of every run. This is the single most valuable reporting step, because it turns a wall of console output into a structured, clickable result.

For pytest, add --junitxml and publish the file:

  - script: pytest -v --junitxml=test-results.xml
    displayName: "Run Vibium tests"
 
  - task: PublishTestResults@2
    condition: succeededOrFailed()
    inputs:
      testResultsFormat: "JUnit"
      testResultsFiles: "test-results.xml"
      testRunTitle: "Vibium browser tests"

The condition: succeededOrFailed() is essential — without it, the publish step is skipped when tests fail, which is exactly when you most need the report. For a Node runner, wire up a JUnit reporter (jest-junit for Jest, or the equivalent for Vitest) so the reporter writes the same XML shape, then point testResultsFiles at it. The result: a failing assertion shows up as a named, timed test case rather than a stack trace buried in logs.

How do I capture screenshots and traces on failure?

Because pipeline runs are headless and remote, a failure screenshot is the fastest way to see what the page actually showed. Save a PNG when a test fails and let a publish task upload it. Vibium's screenshot() returns PNG bytes, so writing it to disk is one line, and full_page=True captures the whole scroll height, not just the viewport.

import os
import pytest
from vibium import browser_sync as browser
 
 
@pytest.fixture
def vibe(request):
    instance = browser.launch(headless=os.getenv("HEADLESS") == "true")
    yield instance
    if request.node.rep_call.failed:
        png = instance.screenshot(full_page=True)
        with open(f"fail-{request.node.name}.png", "wb") as f:
            f.write(png)
    instance.quit()

Then publish the images as a pipeline artifact, gated on failed() so successful runs stay lean:

  - task: PublishPipelineArtifact@1
    condition: failed()
    inputs:
      targetPath: "$(System.DefaultWorkingDirectory)"
      artifact: "vibium-failure-screenshots"

For richer debugging, record a Vibium trace with screenshots and DOM snapshots, publish the resulting trace.zip the same way, and open it in the Vibium Trace viewer to scrub the timeline frame by frame. See taking a full-page screenshot for the capture options and flake-free tests for why a captured artifact beats guessing at a re-run.

How do I cache Chrome to speed up Azure DevOps runs?

Vibium downloads Chrome for Testing once and reuses it, so caching that download trims the vibium install step down to a near-instant restore on later runs. Add the Cache@2 task keyed on your Vibium version, pointing at the directory where Vibium stores its browser, and every subsequent build starts from a warm binary.

  - task: Cache@2
    inputs:
      key: 'vibium-chrome | "$(Agent.OS)" | requirements.txt'
      path: "$(HOME)/.cache/vibium"
    displayName: "Cache Vibium Chrome"
 
  - script: |
      pip install vibium pytest
      vibium install
    displayName: "Install Vibium (warm cache)"

Key the cache on something that changes when you bump Vibium — a lockfile such as requirements.txt or package-lock.json — so a version upgrade correctly invalidates the stale Chrome and re-downloads. This matters most on busy repositories where the pipeline fires on every commit; a warm cache shaves the download off each of those runs. Pair it with parallelizing Vibium tests to keep total pipeline time low as the suite grows.

How do I run Vibium tests in parallel across agents?

Fan a single job across shards with a matrix strategy, and give each test its own browser context so parallel workers never corrupt one another's state. Azure DevOps spins up a fresh agent per matrix leg, each installs Vibium and runs one slice of the suite, and the Tests tab aggregates the results.

strategy:
  matrix:
    shard_1:
      SHARD: "1/3"
    shard_2:
      SHARD: "2/3"
    shard_3:
      SHARD: "3/3"
  maxParallel: 3
 
steps:
  - script: pytest -v --junitxml=results-$(System.JobName).xml --shard=$(SHARD)
    displayName: "Run shard $(SHARD)"

The isolation rule is what keeps this safe: launch one browser per agent, then open a new Context per test — an isolated cookie jar and storage — so tests share a single Chrome launch without sharing cookies. Vibium's auto-waiting find() is doubly valuable under parallel load, because a shared agent under CPU pressure is exactly where hard-coded sleeps become flaky. Publish each shard's JUnit file with a unique name and Azure DevOps merges them into one result view.

Which Azure DevOps agent should I use for Vibium?

Pick the Microsoft-hosted ubuntu-latest agent by default; reach for Windows or self-hosted only when a specific requirement forces it. The table below maps the common situations to the right pool.

For nearly every browser suite, ubuntu-latest is the correct answer: it is the least expensive hosted option, boots quickly, and headless Chrome has no reason to prefer another OS. Choose windows-latest only when you are testing behavior that genuinely differs on Windows. Move to a self-hosted agent when you need access to a private staging environment, want a pinned OS image that will not shift under you, or want to bake Chrome's libraries into the image so no run ever pays for the apt-get.

How do I handle secrets and logins for authenticated tests?

Store credentials in an Azure DevOps variable group (or Key Vault-linked group) and read them from environment variables in your test — never hard-code a password into the repo. Most real suites need to log in, and the agent has no browser session to inherit, so the login runs fresh on every job.

Mark the variable as secret in the pipeline UI or link a variable group, then map it into the step's environment:

  - script: pytest -v --junitxml=test-results.xml
    displayName: "Run authenticated tests"
    env:
      HEADLESS: "true"
      TEST_USER: "$(TEST_USER)"
      TEST_PASSWORD: "$(TEST_PASSWORD)"

Then consume them in the test rather than embedding literals:

import os
from vibium import browser_sync as browser
 
vibe = browser.launch(headless=os.getenv("HEADLESS") == "true")
vibe.go("https://example.com/login")
vibe.find("#email").type(os.getenv("TEST_USER"))
vibe.find("#password").type(os.getenv("TEST_PASSWORD"))
vibe.find("button[type=submit]").click()
# find() auto-waits for the dashboard element to be actionable
assert vibe.find("[data-testid=welcome]").text()
vibe.quit()

Two rules keep this safe. Mark secrets as secret variables so Azure DevOps masks them in logs — a masked value shows as *** even if a test prints it. And prefer a dedicated test account over a real user's credentials, so a leaked value in a log has limited blast radius. For a complete, resilient login flow with semantic selectors, follow automate login with Vibium.

How does Vibium in Azure DevOps compare to Selenium and Playwright?

All three run in Azure DevOps, but they differ sharply in how much agent setup and browser provisioning each demands. This decision table is honest about the trade-offs rather than stacking the deck for Vibium.

When to choose Vibium in Azure DevOps: you want the thinnest possible pipeline — no driver to match, no browser download step to maintain — plus built-in auto-wait and optional AI assertions, especially if you also drive the browser from an agent via Vibium's MCP server. When Selenium fits: you already run a Selenium Grid or need its unmatched browser and language breadth. When Playwright fits: you want its very mature ecosystem, built-in test runner, and trace viewer today.

Be fair to the alternatives: Selenium and Playwright are more established, and Vibium is the newer entrant. Vibium's differentiator here is operational — it collapses the browser-provisioning stage that makes so many Azure DevOps pipelines fragile — not raw ecosystem size. For side-by-side detail, read Vibium vs Playwright and Vibium vs Selenium.

How do I migrate an existing Selenium pipeline to Vibium?

The migration is mostly a subtraction: delete the driver-management and browser-version steps, then swap the test command. If your current azure-pipelines.yml has tasks that download chromedriver, pin a Chrome version, or start a Selenium Grid, those all disappear.

A typical before-and-after on the install portion:

# Before (Selenium): pin Chrome, download matching chromedriver, start display
- script: |
    CHROME_VERSION=$(google-chrome --version | grep -oP '\d+\.\d+\.\d+')
    wget "https://chromedriver.storage.googleapis.com/$CHROME_VERSION/chromedriver_linux64.zip"
    unzip chromedriver_linux64.zip
    export DISPLAY=:99
    Xvfb :99 &
  displayName: "Provision Selenium browser + driver"
 
# After (Vibium): install libs, install Vibium, that is all
- script: |
    sudo apt-get update
    sudo apt-get install -y libnss3 libgbm1 libasound2
    pip install vibium
    vibium install
  displayName: "Install Vibium"

Watch for two gotchas. First, remove any DISPLAY/Xvfb setup — headless Chrome under Vibium needs no virtual display, and a leftover Xvfb just wastes agent time. Second, replace explicit WebDriverWait calls in your tests with Vibium's implicit actionability waits; find() already blocks until the element is ready, so hard waits become dead code. For the code-level translation, follow migrate from Selenium to Vibium and lean on the Page Object Model to keep the ported suite maintainable.

Why is Vibium a clean fit for Azure DevOps?

Three design choices make Vibium pipelines low-maintenance on Azure DevOps. First, the single Go binary plus auto-downloaded Chrome means zero driver management — the session not created version-mismatch error that plagues driver-based builds simply cannot occur. Second, headless is a launch flag driven by one variable, not a separate code path, so the suite you debug locally is byte-for-byte the suite the agent runs. Third, auto-waiting find() keeps tests stable on shared, sometimes-throttled hosted agents without manual sleeps.

Together they remove the three things that most often turn an Azure DevOps run red — driver drift, headless quirks, and timing flakiness — leaving a pipeline whose job step is just pytest or npm test. Layer in the JUnit publish for reporting, failure-screenshot artifacts for debugging, and Chrome caching for speed, and you have a pipeline that scales from a handful of tests to a full suite without the browser-provisioning maintenance tax.

How does this pair with AI agents and MCP?

Deterministic Azure DevOps pipelines and Vibium's MCP server are complementary. Your pipeline runs compiler-checked, repeatable flows for the journeys you know, while an LLM can drive the same engine for exploratory checks — both hit identical find/click/fill/check code paths under the hood.

Vibium ships a built-in MCP server, so an agent in a client like Claude Code can call the very same commands your pipeline executes. That means a page.do('accept the cookie banner') in a scripted test and an agent-issued action are the same operation, not two parallel implementations. To wire an agent to the engine, see Vibium MCP in Claude Code. The practical pattern: keep stable, high-value journeys as page objects in the pipeline for reliability, and reserve AI checks for the parts that change often — all in one repository, one engine.

Next steps

• What is Vibium — the mental model behind the tool.
• Install Vibium — the single binary and what lands on disk.
• Structure a Vibium test suite — the fixture that flips headless.
• Parallelize Vibium tests — fan out across agents safely.
• Flake-free tests — why auto-wait keeps CI green.
• Screenshot command — capture options for failure artifacts.
• Vibium MCP in Claude Code — let an agent drive the same engine.
• Course and Roadmap — go from basics to a production pipeline.