Forem: Orbit A

Bridging the Gap Between Appium and Jira: A Native Approach Using Atlassian Forge

Orbit A — Tue, 14 Apr 2026 12:01:10 +0000

Introduction: The Context-Switching Problem

In mobile automation, the distance between “a test failed” and “a developer fixed it” is often measured in manual steps. You run your Appium suite, wait for the CI/CD pipeline to finish, and then embark on a quest through thousands of lines of logs to find the culprit.

At Orbit A, we’ve seen this bottleneck slow down teams repeatedly. Having already built reporting tools for Playwright, Cypress, JMeter and k6, we set out to solve the mobile reporting puzzle. Our goal was to create a system where test results aren’t just an artifact in a CI console, but a living part of a Jira Issue.

The Architecture: Why Forge?

Most Jira integrations rely on external backends. You send data to a third-party server, which then talks to Jira via REST API.
We decided to go native. By building on Atlassian Forge, we eliminated the “middleman” entirely.

Data Residency: Your test metrics never leave the Atlassian infrastructure. They are stored in Forge Storage, complying with enterprise security standards.
Security: There are no external databases to breach. Authentication is handled via a tenant-specific Security Token, ensuring that only your authorized CI environment can push updates.

Step-by-Step: Integrating Appium with Jira

To make this work for any mobile project, we focused on WebdriverIO (WDIO) as the primary framework. Here is how we structured the integration.

1. Preparing the Environment
First, you need the standard WDIO stack. If you are starting fresh or adding to an existing project:

npm install @wdio/cli @wdio/local-runner @wdio/mocha-framework @wdio/spec-reporter --save-dev

2. The Custom Reporter Logic
The core of the integration is a custom reporter. We’ve designed a template that handles the collection of test states (passed, failed, skipped) and sends a single, optimized payload at the end of the run.

Inside your project, create wdio-jira-reporter.js. Here is the logic we implemented to ensure data integrity:

const WDIOReporter = require('@wdio/reporter').default;
class JiraReporter extends WDIOReporter {
    constructor(options) {
        options = Object.assign(options, { stdout: true });
        super(options);
        // We pull the Jira ID from an env variable to keep it dynamic
        this.issueId = options.issueId || process.env.JIRA_ISSUE_ID;
        this.testResults = [];
        this.isDone = true;
    }
    onTestPass(test) {
        this.testResults.push({ title: test.title, status: 'passed', duration: test._duration || 0 });
    }
    onTestFail(test) {
        this.testResults.push({ title: test.title, status: 'failed', duration: test._duration || 0 });
    }
    async onRunnerEnd(runner) {
        this.isDone = false;
        const failedCount = this.testResults.filter(t => t.status === 'failed').length;

        const payload = {
            token: "YOUR_ORBIT_A_TOKEN", // Generated in Jira Config
            issueId: this.issueId,
            status: failedCount > 0 ? 'failed' : 'passed',
            summary: {
                passed: this.testResults.filter(t => t.status === 'passed').length,
                failed: failedCount,
                duration: runner.duration || 0
            },
            tests: this.testResults
        };
        try {
            await fetch('YOUR_FORGE_WEBTRIGGER_URL', {
                method: 'POST',
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify(payload)
            });
            console.log('[Orbit A] ✅ Results synced to Jira.');
        } catch (e) {
            console.error('[Orbit A] ❌ Sync failed:', e);
        } finally {
            this.isDone = true;
        }
    }
}
module.exports = JiraReporter;

3. Execution via CLI
Linking a run to a specific Jira ticket is handled via environment variables. This makes it incredibly easy to use within GitHub Actions, GitLab CI, or Bitrise:

JIRA_ISSUE_ID=MOB-10010 npx wdio run wdio.conf.js

NotaBene! How to find the Numeric Issue ID:

Open the Jira Issue you are testing.
Look at the URL in your browser. — If you are on a Board: You will see ...&selectedIssue=10010. The number is the ID. — If you are in the direct issue view: You can navigate to Jira ticket → click ‘Actions’ button → click ‘Export XML’ → copy value of ‘key_id’, i.e. {some-name} (here you’ll need to copy 10010)

The Result: A Unified QA View
When the payload hits the Forge Webtrigger, the app validates the token and stores the metrics. Inside Jira, we provide a custom Issue Panel.
When a developer or manager opens 10010, they don’t see a link to a log file - they see a rendered table.

High-level metrics: Overall status and duration.
Test Breakdown: A searchable list of all test cases within that specific run.

Key Takeaway: By surfacing this data directly in the ticket, we’ve seen teams reduce “clarification time” between QA and Dev by up to 40%.

Conclusion: The Orbit A Ecosystem

The release of Appium Test Results for Jira completes our current vision of a unified QA reporting stack. Whether you are running Cypress or Playwright for web, JMeter or k6 for performance, or Appium for mobile, you now have a single, secure way to report back to Jira.

Automated testing shouldn’t just find bugs; it should make them easier to fix.

Explore the Orbit A suite on the Atlassian Marketplace:

Playwright Results for Jira
Appium Test Results for Jira
Cypress Test Results for Jira
k6 Performance Analytics for Jira
JMeter Performance Analytics for Jira

If you found this helpful, follow Orbit A on LinkedIn. We are building a suite of native Atlassian apps for QA and DevOps teams!

Happy testing,
The Orbit A Team

The Ultimate Guide to Integrating JMeter with Jira CI/CD

Orbit A — Thu, 19 Mar 2026 12:29:05 +0000

JMeter is the undisputed king of load testing. It’s powerful, flexible, and handles massive scale. But let’s be honest: sharing JMeter results with your team feels like it’s still 2010.

Usually, the workflow goes like this: The test finishes. You generate an HTML Dashboard. You zip the folder. You open Jira, find the right ticket, and attach a heavy .zip file or a massive .jtl CSV. Your developers and Product Managers then have to download it, unzip it, and try to understand what went wrong.

Performance testing shouldn’t create data silos. When your team is working on a Jira ticket, they need the core performance metrics (Pass/Fail, Response Times, Error Rates) right there on the screen.
Let’s look at how to stop context-switching and push JMeter results directly into Atlassian Jira.

The Hard Way: Custom Plugins and CI/CD Scripts

Many QA teams try to automate this by writing complex bash scripts in Jenkins or GitHub Actions. They use tools to parse the .jtl file, authenticate with Jira's REST API, and post a messy text comment into the issue.

It takes days to set up, tokens expire, and the formatting is always hard to read.

The Smart Way: Direct Webhooks via tearDown Thread Group

Instead of reinventing the wheel, our team at Orbit A released the JMeter Performance Analytics for Jira. It’s a zero-config Atlassian Forge app that allows you to push JMeter metrics directly into the Jira Issue Panel using a simple Webhook.

No custom plugins to install. No Java coding required. Just a native JMeter HTTP Request. Here is how to set it up in 2 minutes.

Step-by-Step Guide

Step 1: Install the App
Head over to the Atlassian Marketplace and install the JMeter Performance Analytics for Jira.

Step 2: Generate Your Webhook
Go to your Jira Apps menu and open the JMeter to Jira Config page. The app will instantly generate your unique Webhook URL and Secret Token.

Step 3: Add a tearDown Thread Group in JMeter
JMeter has a special feature called the tearDown Thread Group, which executes after your main load test finishes. This is the perfect place to send your results!

Right-click your Test Plan -> Add -> Threads (Users) -> tearDown Thread Group.
Inside it, add an JSR223 Sampler paste this script:

import groovy.json.JsonBuilder

def stats = props.get("MY_DETAILED_STATS")
if (stats == null) {
    log.error("No stats found in MY_DETAILED_STATS! Check your Listener.")
    return
}

def reportList = []
long grandTotalTime = 0
int grandTotalCount = 0
int grandTotalErrors = 0

boolean stepFailed = false

stats.each { label, data ->
    def avg = data.totalTime / data.count
    def errRate = (data.errors / data.count) * 100
    errRate = Math.round(errRate * 100.0) / 100.0

    reportList.add([
        label: label,
        avg: avg,
        errorRate: errRate,
        count: data.count
    ])

    if (errRate > 3) {
        stepFailed = true
        log.warn("Step [${label}] failed with ${errRate}% errors")
    }

    grandTotalTime += data.totalTime
    grandTotalCount += data.count
    grandTotalErrors += data.errors
}

long finalAvg = grandTotalCount > 0 ? (grandTotalTime / grandTotalCount) : 0
double finalErr = grandTotalCount > 0 ? ((grandTotalErrors / grandTotalCount) * 100) : 0
finalErr = Math.round(finalErr * 100.0) / 100.0

String finalStatus = "PASS"

if (finalErr > 3 || finalAvg > 3000 || stepFailed) {
    finalStatus = "FAIL"
}

def jsonBuilder = new JsonBuilder(reportList)

props.put("JSON_DETAILS_STRING", jsonBuilder.toString())
props.put("FINAL_AVG", String.valueOf(finalAvg))
props.put("FINAL_ERR", String.valueOf(finalErr))
props.put("FINAL_STATUS", finalStatus)

log.info("Final Stats: Avg=${finalAvg}ms, TotalErr=${finalErr}%, Status=${finalStatus}")
log.info("Detailed report prepared for ${reportList.size()} items.")

Also in tearDown Thread Group add HTTP Request Sampler.

Set the Method to POST and paste your Jira Webhook URL.
Add an HTTP Header Manager and set Content-Type to application/json.
In the Body Data of your HTTP Request, paste this JSON payload:

{
    "token": "${__P(token, YOUR_TOKEN)}", 
    "issueId": "${__P(issueId, ISSUE_ID)}", 
    "avgResponseTime": ${__P(FINAL_AVG, 0)},
    "errorRate": ${__P(FINAL_ERR, 0)},
    "status": "${__P(FINAL_STATUS, PASS)}",
    "details": ${__P(JSON_DETAILS_STRING, [])}
}

Also, don’t forget to fill in:

Server name or IP field with your url like ‘{uuid-from-jira-config-page}.hello.atlassian-dev.net
Path filed with your url’s path part, like : ‘/x1/Z-U7s9ZwttETBesD2ri07HJYBU’

How to find the Numeric Issue ID:
Open the Jira Issue you are testing.
Look at the URL in your browser.
— If you are on a Board: You will see ...&selectedIssue=10023. The number is the ID.
— If you are in the direct issue view: You can navigate to Jira ticket → click ‘Actions’ button → click ‘Export XML’ → copy value of ‘key_id’, i.e. KAN-7 (here you’ll need to copy 10134)

Note: You can trigger this script in your GitHub Actions, GitLab CI, or Jenkins pipeline dynamically passing the current Jira Issue ID based on the branch name!

The Result: Performance at a Glance

The moment your JMeter test finishes, the HTTP request fires, and your developers will instantly see the core metrics right on the Jira issue panel:

They can also click to expand the details and see the exact breakdown of your HTTP Samplers:

Conclusion

By pushing JMeter results directly into Jira, you eliminate ZIP files, reduce manual reporting, and give developers immediate feedback exactly where they track their work.

👉 Try JMeter Performance Analytics for Jira on the Atlassian Marketplace!

If you found this helpful, follow Orbit A on LinkedIn. We are building a suite of native Atlassian apps for QA and DevOps teams!

Stop Sharing Grafana Links: How to Send k6 Load Test Results Directly to Jira

Orbit A — Thu, 12 Mar 2026 12:34:38 +0000

Your k6 load test just finished. The API survived 10,000 virtual users. Now, how do you communicate that success to the product manager and developers?

Usually, it goes like this: The performance engineer takes a screenshot of the terminal, exports a CSV, or drops a Grafana dashboard link into a Jira comment. The developer sees the link, realizes they have to log into another system, and ignores it.

Performance testing shouldn't live in a silo. When developers are working on a Jira ticket to "Optimize Checkout API," they need the performance metrics right there, inside the ticket.

Let's look at how to stop context-switching and push k6 results directly into Atlassian Jira.

The Hard Way: Custom Pipelines and API Tokens

Many DevOps teams try to build this themselves. They write custom scripts to parse the k6 JSON output, authenticate with Jira's REST API using user tokens (which eventually expire), and struggle to format the data into readable tables inside Jira comments.

It takes days to build and constantly requires maintenance.

The Smart Way: Direct Jira Issue Webhooks

Instead of building it from scratch, our team at Orbit A released the k6 Performance Analytics for Jira. It's a zero-config Atlassian Forge app that allows you to push k6 performance metrics directly into the Jira Issue Panel using a simple Webhook.

It natively hooks into the k6 handleSummary() callback, requiring no external dependencies. Here is how to set it up in under 2 minutes.

Step-by-Step Guide

Step 1: Install the App
Head over to the Atlassian Marketplace and install the k6 Performance Analytics for Jira (it's free to try).

Step 2: Generate Your Webhook
Go to your Jira Apps menu and open the k6 to Jira Config page. The app will instantly and securely generate your unique:

Webhook URL.
Secret Token.

Step 3: Add handleSummary to Your k6 Script
k6 has a brilliant built-in feature called handleSummary, which runs at the very end of your test. You simply append this code to your existing k6 script.

Here is the secure, production-ready script. It accurately calculates error rates, pushes the data to Jira, and still preserves your standard terminal output!

const reporterCode = `import http from 'k6/http';
import { textSummary } from 'https://jslib.k6.io/k6-summary/0.0.2/index.js';

export default function () {
  http.get('https://test-api.k6.io');
}

export function handleSummary(data) {
  const issueId = __ENV.JIRA_ISSUE_ID;

  const avgResponseTime = data.metrics.http_req_duration ? data.metrics.http_req_duration.values.avg : 0;
  const reqCount = data.metrics.http_reqs ? data.metrics.http_reqs.values.count : 0;

  const errorRate = data.metrics.http_req_failed ? (data.metrics.http_req_failed.values.rate * 100) : 0;

  const status = (errorRate > 1 || avgResponseTime > 5000) ? "FAIL" : "PASS";

  const payload = JSON.stringify({
    token: "${token}", 
    issueId: issueId,
    status: status,
    avgResponseTime: avgResponseTime,
    errorRate: errorRate,
    transactions: [
      { 
        name: "Total API Requests", 
        avgTime: avgResponseTime, 
        errorRate: errorRate,
        requests: reqCount 
      }
    ]
  });

  if (!issueId) {
     console.log('\\n[Jira Reporter] ⚠️ No JIRA_ISSUE_ID provided. Skipping Jira update.');
     return { 'stdout': textSummary(data, { indent: ' ', enableColors: true }) };
  }

  console.log('\\n[Jira Reporter] Sending performance results to Jira issue: ' + issueId);

  const res = http.post('${webhookUrl}', payload, {
    headers: { 'Content-Type': 'application/json' },
  });

  if (res.status === 200) {
    console.log('[Jira Reporter] ✅ Successfully pushed results to Jira!');
  } else {
    console.log('[Jira Reporter] ❌ Failed to push to Jira. Status: ' + res.status);
  }

  return {
    'stdout': textSummary(data, { indent: ' ', enableColors: true }),
  };
}`;

Note: Trigger this script in your CI/CD pipeline like this: k6 run -e JIRA_ISSUE_ID=PROJ-123 script.js

(Important: Please ensure issueId is the numeric ID, e.g., 10023, not the Key like PROJ-1)

How to find the Numeric Issue ID:
Open the Jira Issue you are testing.
Look at the URL in your browser.

If you are on a Board: You will see ...&selectedIssue=10023. The number is the ID.
If you are in the direct issue view: You can navigate to Jira ticket → click 'Actions' button → click 'Export XML' → copy value of 'key_id', i.e. KAN-7 (here you'll need to copy 10134)

Note: You can trigger this script in your GitHub Actions, GitLab CI, or Jenkins pipeline dynamically passing the current Jira Issue ID based on the branch name!

The Result: Performance at a Glance

The moment your k6 load test finishes, the developer or SRE opening the Jira ticket will instantly see the core metrics right on the issue panel:

They can also click to expand the details and see the exact breakdown of transactions:

Conclusion

By bridging the gap between performance testing tools like k6 and project management tools like Jira, you eliminate data silos. QA engineers stop acting as messenger pigeons, and developers get immediate feedback exactly where they track their work.

👉 [Try k6 Performance Analytics for Jira on the Atlassian Marketplace]

If you found this helpful, be sure to follow Orbit A on LinkedIn. We are building a suite of native Atlassian apps for QA and DevOps teams, including integrations for Playwright, Cypress, and JMeter!

How to Send Cypress Results Directly to Jira Tickets

Orbit A — Wed, 11 Mar 2026 15:11:07 +0000

Your Cypress E2E suite just finished running in your CI/CD pipeline. It caught a regression. Great job!

But what happens next? If your team is like most, the QA engineer has to open the GitHub Actions or Jenkins logs, figure out which spec failed, take a screenshot, and manually paste it into the developer’s Jira ticket with a comment like: “Hey, this broke in the latest build. Here is the link to the logs.”

Cypress is an incredible tool for writing reliable End-to-End tests. But when it comes to communicating those results across the team, the feedback loop is often broken. Developers and Product Managers live in Jira, not in your CI logs.

Let’s look at how to bridge this gap and push Cypress results exactly where the work is happening.

The Old Way: Manual Links and Expensive Dashboards

Historically, teams have tried to solve this in a few ways:

Pasting links: Manually linking to CI logs or HTML reports (like Mochawesome) in Jira comments. It’s tedious, and nobody actually clicks those links.
Building custom integrations: Writing complex Node.js scripts using Atlassian API tokens to format Jira comments. These scripts take days to build and constantly break when tokens expire.
Paying for external dashboards: Using premium cloud dashboards that developers rarely log into anyway because it forces them to context-switch out of Atlassian.

The Smart New Way: Direct Jira Issue Webhooks

Software quality should be visible right inside the Jira ticket that the developer is actively working on.

To solve this, our team at Orbit A built the Cypress Test Results for Jira -> Link to Atlassian Marketplace Is Here! It is a native, zero-config Atlassian Forge app that allows you to push Cypress test results directly into the Jira Issue Panel using a simple Webhook.

No API tokens to manage. No complex formatting. Just a simple JSON payload. Here is how to set it up.

Step-by-Step Guide

Step 1: Install the App
Head over to the Atlassian Marketplace and install the Cypress Test Results for Jira (it’s free to try).
Step 2: Generate Your Webhook
Go to your Jira Apps menu and open the Cypress to Jira page. The app will securely generate:

A Webhook URL.
A Secret Token.

Step 3: Add a POST Request to Your CI Pipeline
Once your Cypress tests finish running, you usually have a JSON report (for example, generated by Mochawesome or a custom Cypress reporter). You can simply parse that report and send it to Jira using Node.js or curl.

Here is an example of a simple Node.js script you can run in your after:run hook or as a separate CI step:

// cypress-jira-reporter.js
const Mocha = require('mocha');
const { EVENT_RUN_END, EVENT_TEST_PASS, EVENT_TEST_FAIL, EVENT_TEST_PENDING } = Mocha.Runner.constants;

class JiraReporter extends Mocha.reporters.Base {
  constructor(runner, options) {
    super(runner);

    const reporterOptions = options.reporterOptions || {};
    const issueId = reporterOptions.issueId || process.env.JIRA_ISSUE_ID;
    const webhookUrl = reporterOptions.webhookUrl || process.env.JIRA_WEBHOOK_URL;
    const token = reporterOptions.token || process.env.JIRA_WEBHOOK_TOKEN;

    const stats = { passed: 0, failed: 0, skipped: 0, duration: 0 };
    const tests = [];

    runner.on(EVENT_TEST_PASS, (test) => {
      stats.passed++;
      tests.push({ title: test.title, status: 'passed', duration: test.duration || 0 });
    });

    runner.on(EVENT_TEST_FAIL, (test) => {
      stats.failed++;
      tests.push({ title: test.title, status: 'failed', duration: test.duration || 0 });
    });

    runner.on(EVENT_TEST_PENDING, (test) => {
      stats.skipped++;
      tests.push({ title: test.title, status: 'skipped', duration: 0 });
    });

    runner.on(EVENT_RUN_END, async () => {
      stats.duration = Date.now() - this.startTime;

      const overallStatus = stats.failed > 0 ? 'failed' : 'passed';

      const payload = {
        token: token,
        issueId: issueId,
        status: overallStatus,
        summary: stats,
        tests: tests
      };

      if (!webhookUrl || !token || !issueId) {
         console.warn('\n[Jira Reporter] ⚠️ Missing Webhook URL, Token, or Issue ID. Skipping Jira update.');
         return;
      }

      console.log('\n[Jira Reporter] Sending results to Jira issue:', issueId);

      try {
        await fetch(webhookUrl, {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify(payload)
        });
        console.log('[Jira Reporter] ✅ Successfully pushed results to Jira!');
      } catch (e) {
        console.error('[Jira Reporter] ❌ Error sending payload to Jira:', e);
      }
    });

    this.startTime = Date.now();
  }
}

module.exports = JiraReporter;

(Important: Please ensure issueId is the numeric ID, e.g., 10023, not the Key like PROJ-1)

How to find the Numeric Issue ID:

Open the Jira Issue you are testing.
Look at the URL in your browser.
If you are on a Board: You will see ...&selectedIssue=10023. The number is the ID.
If you are in the direct issue view: You can navigate to Jira ticket → click ‘Actions’ button → click ‘Export XML’ → copy value of ‘key_id’, i.e. KAN-7 (here you’ll need to copy 10134)

Note: You can trigger this script in your GitHub Actions, GitLab CI, or Jenkins pipeline dynamically passing the current Jira Issue ID based on the branch name!

The Result: Total Visibility

The moment your CI pipeline finishes, any developer or PM opening the Jira ticket will instantly see this on the right-side panel:

They don’t need to ask for test results history. They can click on the Select Run tab to see 5 latest test runs and their results:

Conclusion

By integrating Cypress directly with Jira, you eliminate context-switching. QA engineers stop acting as log-couriers, and developers get immediate feedback exactly where they track their work.

👉 Try Cypress Test Results for Jira on the Atlassian Marketplace -> Link to Atlassian Marketplace!

If you found this helpful, be sure to follow Orbit A on LinkedIn. We are building a suite of tools to bridge the gap between testing and project management, including native integrations for Playwright, k6, and JMeter!

The Ultimate Guide to Tracking Playwright Automation Results in Jira Issues

Orbit A — Thu, 05 Mar 2026 13:19:03 +0000

You wrote a beautiful, rock-solid Playwright test suite. It caught a critical bug in the CI pipeline. Splendid!

…And then you spend the next 15 minutes explaining to the developer which pipeline ran, where to find the logs, and manually pasting screenshots of the failed assertions into a Jira ticket. Not awesome.

If your team uses Playwright, you know it’s incredibly fast and reliable. But communicating those test results across the team is still a manual, context-switching nightmare. Software quality shouldn’t live in a siloed CI/CD black hole — it should live exactly where your team tracks their work: in Jira.

Let’s look at how to fix this workflow once and for all.

The Hard Way: Custom Scripts and Jira API Nightmares

Usually, when QA engineers or DevOps teams try to automate sending test results to Jira, they go down the rabbit hole of building custom integrations:

Creating Atlassian API tokens (which eventually expire and break the pipeline).
Writing complex Node.js scripts to parse Playwright’s JSON reports.
Wrestling with Jira’s Atlassian Document Format (ADF) just to format a simple table in a comment.

It takes days to build and constantly requires maintenance.

The Smart Way: Webhook Integration

Instead of building a custom integration from scratch, you can use a native Atlassian Forge app that does the heavy lifting for you.

My team at Orbit A recently released the Playwright Results for Jira >>> Link to Atlassian Marketplace. It’s a zero-config app that generates a secure Webhook URL for your Jira project. You just send a simple JSON payload to this URL, and it instantly renders beautiful charts and tables right inside the Jira Issue Panel.

Here is how you can set it up in under 2 minutes.

Step-by-Step Guide

Step 1: Install the App
Head over to the Atlassian Marketplace and install the Playwright Integration for Jira (it’s free to try).

Step 2: Generate Your Webhook
Once installed, go to your Jira Apps menu and open the Playwright Configuration page. Click “Generate Webhook”. You will get two things:

A Webhook URL.
A secure Token.

Step 3: Add a Simple POST Request to Your Pipeline
You don’t need any complex dependencies. After your Playwright tests finish running (and generate a JSON report), you can use a simple Node script or a curl command to push the data to Jira.

Create a file named jira-reporter.js in your Playwright project root.
Paste the code below into it.
Run tests: JIRA_ISSUE_ID=10001 npx playwright test --reporter=./jira-reporter.js

const reporterCode = `// playwright-jira-reporter.js
class JiraReporter {
  constructor(options = {}) {
    this.issueId = options.issueId || process.env.JIRA_ISSUE_ID;
  }

  onBegin(config, suite) {
    this.suite = suite;
    this.startTime = Date.now();
  }

  async onEnd(result) {
    const duration = Date.now() - this.startTime;
    const stats = { passed: 0, failed: 0, skipped: 0, duration: duration };
    const tests = [];

    const traverse = (suite) => {
      for (const test of suite.tests) {
        const outcome = test.results[test.results.length - 1];
        if (!outcome) continue;

        let mappedStatus = 'skipped';
        if (outcome.status === 'passed') {
          stats.passed++;
          mappedStatus = 'passed';
        } else if (outcome.status === 'failed' || outcome.status === 'timedOut' || outcome.status === 'interrupted') {
          stats.failed++;
          mappedStatus = 'failed';
        } else {
          stats.skipped++;
        }

        tests.push({
          title: test.title,
          status: mappedStatus,
          duration: outcome.duration || 0
        });
      }
      for (const child of suite.suites) traverse(child);
    };

    traverse(this.suite);

    const overallStatus = stats.failed > 0 ? 'failed' : 'passed';

    const payload = {
      token: "${token}", // Auto-injected by Jira
      issueId: this.issueId,
      status: overallStatus,
      summary: stats,
      tests: tests
    };

    if (!this.issueId) {
       console.warn('\\n[Jira Reporter] No JIRA_ISSUE_ID provided. Skipping Jira update.');
       return;
    }

    console.log('\\n[Jira Reporter] Sending report to Jira issue:', this.issueId);

    try {
      await fetch('${webhookUrl}', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(payload)
      });
      console.log('[Jira Reporter] ✅ Successfully sent to Jira!');
    } catch (e) {
      console.error('[Jira Reporter] ❌ Failed to send to Jira:', e);
    }
  }
}

module.exports = JiraReporter;`;

(Important: Please ensure issueId is the numeric ID, e.g., 10023, not the Key like PROJ-1)
How to find the Numeric Issue ID:

Open the Jira Issue you are testing.
Look at the URL in your browser. — If you are on a Board: You will see ...&selectedIssue=10023. The number is the ID. — If you are in the direct issue view: You can navigate to Jira ticket → click ‘Actions’ button → click ‘Export XML’ → copy value of ‘key_id’, i.e. KAN-7 (here you’ll need to copy 10134)

Note: You can trigger this script in your GitHub Actions, GitLab CI, or Jenkins pipeline dynamically passing the current Jira Issue ID based on the branch name!

The Result: No More Context Switching
As soon as the pipeline finishes, the developer or PM opening the Jira ticket will see this immediately on the right-side panel:

They don’t need to ask for test results history. They can click on the Select Run tab to see 5 latest test runs and their results:

Conclusion
Stop acting as a human bridge between your CI/CD pipelines and Jira. By pushing Playwright results directly into Atlassian, you save time, reduce friction between QA and Development, and make software quality visible to everyone.

👉 Try Playwright Integration for Jira on the Atlassian Marketplace >>> Here is the Link

If you found this helpful, follow Orbit A on LinkedIn https://www.linkedin.com/company/orbit-a-apps/ for more tips on bridging the gap between testing and project management. We also have native integrations for Cypress, k6, and JMeter!