A custom reporter for Playwright that automatically creates bugs in Azure DevOps when tests fail.

Installation | Usage | Configuration | Authentication | Pipeline | Advanced

• Automatically creates bugs in Azure DevOps when Playwright tests fail
• Configurable bug creation policies to prevent duplicate bugs
• Support for custom fields and area paths
• Automatic attachment upload (screenshots, videos, logs)
• Flexible iteration path handling (current, next, backlog)
• Customizable bug properties (severity, assigned to, etc.)

npm install @solvexus/playwright-azure-bug-reporter

Add the reporter to your Playwright configuration file (playwright.config.ts):

import { AzureBugReporterConfig } from "@solvexus/playwright-azure-bug-reporter/dist/reporter-config"; const config: PlaywrightTestConfig = { reporter: [ ["list"], [ "@solvexus/playwright-azure-bug-reporter", { organization: "your-org", project: "your-project", token: process.env.AZURE_PAT, areaPath: "Your-Project\\Area\\Path", // Optional configurations title: (test) => `Failed Test: ${test.title}`, severity: "2 - High", bugCreationPolicy: "if-none-open", uploadAttachments: true, } as AzureBugReporterConfig, ], ], // ... rest of your config };

For more information about configuring reporters in Playwright, see the Playwright Reporters documentation.

* Example of custom HTML repro steps:

(test, result) => `<div>  <b>Test File:</b> ${test.location?.file}<br>  <b>Line:</b> ${test.location?.line}<br>  <b>Status:</b> ${result.status}<br>  <b>Error:</b> ${result.error?.message || "N/A"}<br>  <b>Stack:</b><br><pre>${result.error?.stack || "N/A"}</pre>  </div>`;

All configuration options can be provided as static values, example:

severity: "2 - High";

or functions of the test case and result, example:

severity: (test, result) => result.error?.message?.includes("critical") ? "1 - Critical" : "2 - High";

This reporter uses a Personal Access Token (PAT) to create bugs in Azure DevOps. Your PAT must have the following permissions:

• Work Items (Read & Write)
• Analytics (Read)

You can find instructions how to generate a PAT in the Microsoft Documentation.

During local development, you can store your PAT in a .env file. Be sure to add .env to your .gitignore to avoid leaking it. Then you can use it in playwright.config.ts (see configuration):

 { token: process.env.AZURE_PAT, }

If you are running your Playwright script in an Azure Pipeline (see below), then you can add the token as a pipeline variable:

• Go to your pipeline settings
• Click "Variables", "New variable"
• Name: AZURE_PAT
• Value: Paste your PAT
• Check "Keep this value secret"
• Click "OK"

To run your Playwright tests in Azure Pipelines and automatically create bugs for failed tests, create a azure-pipelines.yml file in your repository:

trigger: none # Disables triggers on branch pushes schedules: - cron: "0 0 * * *" # Runs at midnight every day (UTC) displayName: "Daily Midnight Schedule" branches: include: - main # Only triggers on the 'main' branch always: true # Ensures the pipeline runs even if there are no changes pool: name: Self-hosted # Put your pool argument here, where you want to run this pipeline steps: - task: UseNode@1 inputs: version: "20.x" # Use your version of Node here - script: npm install displayName: "npm install" - script: npx playwright install --with-deps displayName: "Install Playwright browsers" - script: npx playwright test displayName: "Run Playwright tests" env: CI: "true" AZURE_PAT: "$(AZURE_PAT)" # Used by playwright-azure-bug-reporter continueOnError: true

The pipeline will:

1. Install Node.js and project dependencies
2. Install Playwright browsers
3. Run tests
4. Create bugs in Azure DevOps for failed tests

The bugCreationPolicy option controls when a new bug should be created in Azure DevOps to help you avoid duplicate reports.

• if-none-open (default): A new bug is created only if there are no matching open bugs. This is the most common use case.
• if-none: A new bug is created only if no matching bug exists at all, regardless of its status (open or closed).
• always: A new bug is created for every test failure, even if a matching bug already exists.

Matching is determined using the bugSignature field, which uniquely identifies each bug. By default, this is set to test.title and is stored in a custom field called Custom.BugSignature.

Tip: You can customize the signature logic by providing your own function for bugSignature.

If the Custom.BugSignature field does not exist in your Azure DevOps project, the reporter will automatically create it (unless you disable this with allowFieldCreation: false).

Note: The automatically created field is hidden by default. To make it visible in your bug layout, follow Microsoft's instructions to show custom fields.

Area paths help organize work items in Azure DevOps. The reporter can automatically create paths:

{ // Area path format: Project\Area\Subarea areaPath: "MyProject\\QA\\Automated", // Control area path creation allowAreaPathCreation: true }

Iteration paths define sprints/milestones. Supported formats:

• "current": Current sprint
• "next": Next sprint
• "backlog": Project backlog
• Custom path: "MyProject\\Release 1\\Sprint 2"

{ iterationPath: "current", // Use current sprint // or iterationPath: "MyProject\\Release 1\\Sprint 2" // Custom path }

You can limit the number of bugs created in a single test run using the maximumNumberOfBugs option:

{ // Limit to 10 bugs per test run maximumNumberOfBugs: 10, // Or use a function to determine the limit dynamically maximumNumberOfBugs: (test, result) => process.env.NODE_ENV === 'production' ? 5 : 20 }

When the limit is reached, the reporter will log a message indicating that the maximum number of bugs has been reached and skip creating bugs for any subsequent test failures.

• src/ - Source code files
• dist/ - Compiled JavaScript files and type definitions
• playwright-azure-bug-reporter.js - Main entry point
• playwright-azure-reporter.d.ts - TypeScript type definitions

To build the project:

npm install npm run build

Contributions are welcome! Please feel free to submit a Pull Request.

1. Fork the repository
2. Create your feature branch (git checkout -b feature/amazing-feature)
3. Commit your changes (git commit -m 'Add some amazing feature')
4. Push to the branch (git push origin feature/amazing-feature)
5. Open a Pull Request

This project is licensed under the MIT License - see the LICENSE file for details.

Mounir Bendouch - Solvexus

For support, issues, or feature requests, please file an issue.