How to Export GitHub Actions Test Results to HP ALM / OpenText ALM

If you're running tests in GitHub Actions and managing test cases in HP ALM (now OpenText ALM / Quality Center), you've probably noticed: there's no official integration between the two.

OpenText provides a GitHub Action for ALM Octane — but that's for Octane, not classic ALM/Quality Center. For the version of ALM that most enterprise teams actually use, you're on your own.

That means one of three things:

1. Manual uploads — someone downloads test results from GitHub Actions and enters them in ALM by hand
2. Custom scripts — a pipeline step calls the ALM REST API directly, with all the fragility that entails
3. Nothing — results live in GitHub Actions and never make it to ALM

BuildButler solves this with a single integration that bridges GitHub Actions and ALM automatically.

The gap in ALM's CI/CD support

OpenText's Jenkins integration is mature — the Application Automation Tools plugin handles test result upload with YAML-based field mapping. But for GitHub Actions, there's nothing equivalent.

This matters because many enterprise teams are migrating from Jenkins to GitHub Actions (or running both). Their ALM workflows — Test Plans, Test Lab, defect management — don't change. But the pipeline that feeds results into ALM does.

How BuildButler bridges the gap

BuildButler connects to GitHub Actions and exports test results to ALM on every workflow run. The same JSON configuration that works for Jenkins works for GitHub Actions — no separate tooling needed.

What happens on each workflow run

1. GitHub Actions completes a workflow with test results (JUnit, TestNG, TRX, Allure, Cucumber, or Robot format)
2. BuildButler collects the results via the CLI reporter or API
3. Pattern-matching rules route results to the correct ALM domain, project, and Test Plan directory
4. Test cases are looked up in Test Plan (or created if using create-minimal mode)
5. A test set is created in Test Lab with a dynamic name
6. Defects are created, reopened, or closed based on your policies

Configuration

The same JSON rules work for GitHub Actions as for Jenkins:

[
  {
    "jobPattern": "backend/*",
    "domain": "DEFAULT",
    "project": "BackendSuite",
    "testPlanDirectory": "Subject\\Automated\\Backend",
    "testLabDirectory": "Root\\Automated\\{jobName}",
    "testSet": "{jobName} #{buildNumber}"
  }
]

Template variables ({jobName}, {buildNumber}, {branch}) resolve to GitHub Actions workflow and run metadata.

Automatic defect management

The same ALM defect management that works with Jenkins works with GitHub Actions:

• Create defects for failing tests
• Reopen defects for recurring failures
• Close defects when tests pass again

No separate configuration. No additional setup.

Running Jenkins and GitHub Actions together?

Many teams run both during a migration. BuildButler handles this natively — the same ALM mapping rules apply regardless of which CI system produces the results. Test cases, test sets, and defects in ALM are unified across both CI systems.

Supported test formats

• JUnit XML
• TestNG XML
• TRX (.NET)
• Allure JSON
• Cucumber JSON
• Robot Framework XML

Getting started

1. Sign up for BuildButler — ALM integration is included on all plans
2. Add the BuildButler CLI reporter to your GitHub Actions workflow
3. Configure your ALM credentials (HP ALM / Micro Focus ALM / OpenText ALM) in System Settings
4. Define your job mapping rules
5. Push a commit — results flow to ALM on the next workflow run

See the full ALM integration guide for configuration details.