How to Export GitLab CI Test Results to HP ALM / OpenText ALM

GitLab CI is one of the fastest-growing CI/CD platforms. HP ALM (now OpenText ALM / Quality Center) is one of the most entrenched test management tools in the enterprise. And there's almost no content on the internet about connecting the two.

That's because there's no official integration. OpenText provides a Jenkins plugin and an ALM Octane GitHub Action, but nothing for GitLab CI and classic ALM/Quality Center. If your team uses both, you're left with manual uploads or custom REST API scripts.

BuildButler fills this gap.

Why this integration doesn't exist natively

OpenText's CI/CD strategy has focused on Jenkins (via the Application Automation Tools plugin) and their own ALM Octane product. GitLab CI integration for classic ALM/Quality Center was never prioritized.

Meanwhile, teams that adopted GitLab CI still need to report results into ALM — because ALM is where QA managers track coverage, compliance teams audit test execution, and release gates are enforced.

The result: QA engineers manually download JUnit XML from GitLab CI artifacts and upload them to ALM. Or someone writes a .gitlab-ci.yml stage that calls the ALM REST API directly — and maintains that script forever.

How BuildButler connects GitLab CI to ALM

BuildButler sits between your GitLab CI pipelines and ALM. You configure mapping rules once, and test results flow automatically after every pipeline run.

Setup

1. Add the BuildButler CLI reporter to your .gitlab-ci.yml as a pipeline stage
2. Configure ALM credentials in BuildButler System Settings
3. Define JSON mapping rules that route GitLab CI jobs to ALM projects

What happens on each pipeline run

1. GitLab CI completes a job with test results (JUnit, TestNG, TRX, Allure, Cucumber, or Robot)
2. The BuildButler CLI reporter sends results to BuildButler
3. Pattern-matching rules route results to the correct ALM domain, project, and Test Plan
4. Test cases are looked up or created in Test Plan
5. A test set is created in Test Lab
6. Defects are created, reopened, or closed based on your policies

Configuration example

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

The same rules work regardless of whether results come from GitLab CI, Jenkins, or GitHub Actions.

Automatic defect management

BuildButler's ALM defect management works with GitLab CI the same way it does with Jenkins:

• Create defects for failing tests with configurable severity and status
• Reopen defects for tests that start failing again
• Close defects when corresponding tests pass

Migrating from Jenkins to GitLab CI?

If your team is moving pipelines from Jenkins to GitLab CI, your ALM integration doesn't have to change. BuildButler uses the same mapping rules for both CI systems. Migrate your pipelines at your own pace — ALM results keep flowing from whichever system runs the build.

Bumblebee-compatible

If you previously used Bumblebee with Jenkins and are now moving to GitLab CI, BuildButler supports the same ALM Field Mappings XML format. Your existing custom field mappings carry over.

Getting started

1. Sign up for BuildButler — ALM integration is included on all plans
2. Add the BuildButler CLI reporter stage to your .gitlab-ci.yml
3. Configure your HP ALM / Micro Focus ALM / OpenText ALM credentials
4. Define your job mapping rules
5. Run a pipeline — results appear in ALM automatically

See the full ALM integration guide for configuration details.