[{"data":1,"prerenderedAt":828},["ShallowReactive",2],{"/en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0":3,"navigation-en-us":40,"banner-en-us":450,"footer-en-us":460,"blog-post-authors-en-us-Martin Brümmer|Fabian Zimmer|Sam Wiskow":701,"blog-related-posts-en-us-a-guide-to-the-breaking-changes-in-gitlab-18-0":740,"assessment-promotions-en-us":779,"next-steps-en-us":818},{"id":4,"title":5,"authorSlugs":6,"body":10,"categorySlug":11,"config":12,"content":16,"description":10,"extension":28,"isFeatured":14,"meta":29,"navigation":30,"path":31,"publishedDate":24,"seo":32,"stem":36,"tagSlugs":37,"__hash__":39},"blogPosts/en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","A Guide To The Breaking Changes In Gitlab 18 0",[7,8,9],"martin-brmmer","fabian-zimmer","sam-wiskow",null,"product",{"slug":13,"featured":14,"template":15},"a-guide-to-the-breaking-changes-in-gitlab-18-0",false,"BlogPost",{"title":17,"description":18,"authors":19,"heroImage":23,"date":24,"body":25,"category":11,"tags":26},"A guide to the breaking changes in GitLab 18.0","Prepare now for the removals in our upcoming major release. Assess your impact and then review the mitigation steps provided in the documentation to ensure a smooth transition to GitLab 18.0.",[20,21,22],"Martin Brümmer","Fabian Zimmer","Sam Wiskow","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","2025-04-18","GitLab 18.0, our next major release, will be packed with new features that push the boundaries of DevSecOps innovation. At the same time, we’ll be removing some deprecated features from GitLab. Here is what you need to know about these breaking changes and how you can mitigate their impact.\n\n## Deployment windows\n\n### GitLab.com\n\nBreaking changes for GitLab.com will be limited to these three windows.\n\n- April 21-23, 2025\n- April 28-30, 2025\n- May 5-7, 2025\n\nMany other changes will continue to roll out throughout the month. You can learn more about the high-impact changes occurring within each of these windows in this [breaking changes documentation](https://docs.gitlab.com/update/breaking_windows/).\n\n***Note:** Breaking changes may fall slightly outside of these windows in exceptional circumstances.*\n\n### GitLab Self-Managed\n\nGitLab 18.0 will be available starting on May 15. You can learn more about the release schedule [here](https://about.gitlab.com/releases/categories/releases/).\n\n### GitLab Dedicated\n\nThe upgrade to GitLab 18.0 will take place during your maintenance window from June 24-29, 2025. You can learn more and find your assigned maintenance window [here](https://docs.gitlab.com/administration/dedicated/maintenance/#release-rollout-schedule).\n\nWe’ve also developed custom tooling and resources to help you assess the impact of these changes on your environment and plan any necessary actions ahead of the 18.0 upgrade. You can find [information about these mitigation tools and resources](#tools-and-resources-to-manage-your-impact).\n\nVisit the [Deprecations page](https://docs.gitlab.com/ee/update/deprecations?removal_milestone=18.0) to see a full list of items scheduled for removal in 18.0. Read on to learn what’s coming and how to prepare for this year’s release based on your specific deployment.\n\n## Breaking changes\n\n### High impact\n\n**1. CI/CD job token - “Limit access from your project” setting removal**\n\nGitLab.com | Self-Managed | Dedicated\n\nIn GitLab 14.4, we introduced a setting to **[limit access *from* your project's CI/CD job tokens (CI_JOB_TOKEN)](https://docs.gitlab.com/ci/jobs/ci_job_token/#limit-your-projects-job-token-access)** for added security. This setting was called **Limit CI_JOB_TOKEN access**. In GitLab 16.3, we renamed this setting **Limit access *from* this project** for clarity.\n\nIn GitLab 15.9, we introduced an alternative setting called **[Authorized groups and projects](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-group-or-project-to-the-job-token-allowlist)**. This setting controls job token access to your project by using an allowlist. This new setting is a significant improvement over the original. The first iteration was deprecated in GitLab 16.0 and scheduled for removal in GitLab 18.0.\n\nThe **Limit access *from* this project** setting is disabled by default for all new projects. In GitLab 16.0 and later, you cannot re-enable this setting after it is disabled in any project. Instead, use the **Authorized groups and projects** setting to control job token access to your projects.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#cicd-job-token---limit-access-from-your-project-setting-removal)\n- [GitLab Detective check available](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**2. CI/CD job token - Authorized groups and projects allowlist enforcement**\n\nGitLab.com | Self-Managed | Dedicated\n\nWith the **[Authorized groups and projects setting](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-group-or-project-to-the-job-token-allowlist)** introduced in GitLab 15.9 (renamed from **Limit access to this project** in GitLab 16.3), you can manage CI/CD job token access to your project. When set to **Only this project and any groups and projects in the allowlist**, only groups or projects added to the allowlist can use job tokens to access your project.\n\n* **Prior to GitLab 15.9**, the allowlist was disabled by default ([**All groups and projects**](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-any-project-to-access-your-project) access setting selected), allowing job token access from any project.\n* **Since GitLab 17.6**, administrators for GitLab Self-Managed and Dedicated instances have had the option to [**enforce a more secure setting for all projects**](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#job-token-permissions), which prevents project maintainers from selecting **All groups and projects**. This change ensures a higher level of security between projects.\n* In GitLab 18.0, this setting will be enabled by default. On GitLab.com, we will automatically populate your projects’ allowlists based on your project authentication logs.\n* To prepare for this change on **GitLab.com**, project maintainers using the job token for cross-project authentication should populate their project's **Authorized groups and projects** allowlists. They should then change the setting to **Only** **this project and any groups and projects in the allowlist**. We encourage the use of available [migration tooling](https://docs.gitlab.com/ci/jobs/ci_job_token/#auto-populate-a-projects-allowlist) to ***automate*** the creation of the allowlist based on the project’s [authentication logs](https://docs.gitlab.com/ci/jobs/ci_job_token/#job-token-authentication-log) prior to GitLab 18.0.\n* **Self-Managed users** should populate the allowlists before completing the 18.0 upgrade.\n* **Dedicated users** should work with their GitLab account team to develop the appropriate strategy for their specific instance.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#cicd-job-token---authorized-groups-and-projects-allowlist-enforcement)\n- [Documentation](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-gr)\n- [GitLab Detective check available](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**3. Dependency Proxy token scope enforcement**\n\nGitLab.com | Self-Managed | Dedicated\n\nThe Dependency Proxy for containers accepts **`docker login`** and **`docker pull`** requests using **personal, project,** or **group** access tokens without validating their scopes.\n\nIn GitLab 18.0, the Dependency Proxy will require both **`read_registry`** and **`write_registry`** scopes for authentication. After this change, authentication attempts using tokens without these scopes will be **rejected**.\n\nBefore upgrading, create new access tokens with the [**required scopes**](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy-for-container-images), and update your workflow variables and scripts with these new tokens.\n\nYou also have the option to use [**Dependency Token Checker**](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/dependancy-token-checker/), a community-developed script that allows you to view tokens and rotate them automatically.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#dependency-proxy-token-scope-enforcement)\n\n### Medium impact\n\n**1. New data retention limits for vulnerabilities on GitLab.com**\n\nGitLab.com - **Ultimate tier customers only**\n\nStarting in GitLab 18.1 with a phased six-month rollout, we will be introducing a **new data retention limit** for GitLab.com **Ultimate** customers to improve system performance and reliability. The data retention limit affects how long your vulnerability data is stored.\n\nVulnerabilities older than 12 months that have not been updated will be automatically moved to cold storage archives. These archives:\n\n* Remain accessible and downloadable through the GitLab UI\n* Are retained for 3 years\n* Are permanently deleted after 3 years\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#new-data-retention-limits-for-vulnerabilities-on-gitlabcom)\n- [Documentation](https://handbook.gitlab.com/handbook/security/records-retention-deletion/)\n\n**2. Reject container image pull policies not in `allowed_pull_policies`**\n\nGitLab.com | Self-Managed | Dedicated\n\nAll configured pull policies should be present in the [**allowed_pull_policies configuration**](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies) specified in the runner's **`config.toml`** file. If they are not, the job should fail with an **`incompatible pull policy`** error.\n\nIn the current implementation, when multiple pull policies are defined, jobs pass if at least one pull policy matches those in **`allowed-pull-policies`**, even if other policies are not included.\n\nIn GitLab 18.0, jobs will fail only if none of the pull policies match those in **`allowed-pull-policies`**. However, unlike past behavior, jobs will use only the pull policies listed in **`allowed-pull-policies`**. This distinction can cause jobs that currently pass to fail in GitLab 18.0.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#reject-container-image-pull-policies-not-in-allowed_pull_policies)\n- [Documentation](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies)\n\n**3. PostgreSQL 14 and 15 no longer supported**\n\nSelf-Managed\n\nGitLab follows an [**annual upgrade cadence for PostgreSQL**](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/).\n\nSupport for PostgreSQL 14 and 15 is scheduled for removal in GitLab 18.0. In GitLab 18.0, PostgreSQL 16 becomes the minimum required version of PostgreSQL.\n\nPostgreSQL 14 and 15 will be supported for the full GitLab 17 release cycle. PostgreSQL 16 will also be supported for instances that want to upgrade prior to GitLab 18.0.\n\nTo prepare for this change on instances that don't use [**PostgreSQL Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) (for example, if you are running a single PostgreSQL instance you installed with an Omnibus Linux package), upgrades to GitLab 17.11 will attempt to automatically upgrade PostgreSQL to Version 16. If you use [**PostgreSQL Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) or [**opt out of this automated upgrade**](https://docs.gitlab.com/omnibus/settings/database/#opt-out-of-automatic-postgresql-upgrades), you must [**manually upgrade to PostgreSQL 16**](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server) to be able to upgrade to GitLab 18.0. Make sure you have sufficient disk space to accommodate the upgrade.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#postgresql-14-and-15-no-longer-supported)\n- [Documentation](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n- [Migration guidelines](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions/)\n\n**4. Deprecate the Terraform CI/CD templates**\n\nSelf-Managed\n\nThe Terraform CI/CD templates are deprecated and will be removed in GitLab 18.0. This affects the following templates:\n\n* `Terraform.gitlab-ci.yml`\n* `Terraform.latest.gitlab-ci.yml`\n* `Terraform/Base.gitlab-ci.yml`\n* `Terraform/Base.latest.gitlab-ci.yml`\n\nGitLab won't be able to update the **`terraform`** binary in the job images to any version that is licensed under the BSL.\n\nTo continue using Terraform, clone the templates and [**Terraform image**](https://gitlab.com/gitlab-org/terraform-images), and maintain them as needed. GitLab provides [**detailed instructions**](https://gitlab.com/gitlab-org/terraform-images) for migrating to a custom-built image.\n\n**As an alternative, we recommend using the new OpenTofu CI/CD component on GitLab.com or the new OpenTofu CI/CD template on GitLab Self-Managed.** CI/CD components are not yet available on GitLab Self-Managed, however, [**Issue #415638**](https://gitlab.com/gitlab-org/gitlab/-/issues/415638) proposes adding this feature. If CI/CD components become available on GitLab Self-Managed, the OpenTofu CI/CD template will be removed.\n\nRead more about the new [OpenTofu CI/CD component](https://gitlab.com/components/opentofu).\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#deprecate-terraform-cicd-templates)\n\n**5. Major update of the Prometheus subchart**\n\nSelf-Managed\n\nWith GitLab 18.0 and GitLab chart 9.0, the Prometheus subchart will be updated from 15.3 to 27.3.\n\nAlong with this update, Prometheus 3 will be shipped by default.\n\nManual steps are required to perform the upgrade. If you have Alertmanager, Node Exporter, or Pushgateway enabled, you will also need to update your Helm values.\n\nPlease refer to the [**migration guide**](https://docs.gitlab.com/charts/releases/9_0/#prometheus-upgrade) for more information.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#major-update-of-the-prometheus-subchart)\n\n### Low impact\n\n**1. No longer building SUSE Linux Enterprise Server 15 SP2 packages**\n\nSelf-Managed\n\nLong-term service and support (LTSS) for SUSE Linux Enterprise Server (SLES) 15 SP2 ended in December 2024.\n\nTherefore, we will no longer support the SLES SP2 distribution for Linux package installs. You should upgrade to SLES 15 SP6 for continued support.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#support-for-suse-linux-enterprise-server-15-sp2)\n\n**2. Remove Gitaly rate limiter**\n\nSelf-Managed\n\nGitaly used to support [**RPC-based rate limiting**](https://gitlab.com/gitlab-org/gitaly/-/blob/4b7ea24f6172a03e7989879200b47b6fd0e2d059/doc/backpressure.md#L55-55). We are deprecating this feature as it does not achieve the desired results. Please see the deprecation issue for details.\n\nIf customers have the rate limiter configured (which is being deprecated), no error will be returned and the config will simply be ignored.\n\nCustomers should utilize the [**Concurrency Limiter**](https://docs.gitlab.com/administration/gitaly/concurrency_limiting/) instead.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#gitaly-rate-limiting)\n\n**3. Deprecate NGINX controller image 1.3.1 support**\n\nSelf-Managed\n\nWe're upgrading the default NGINX controller image to 1.11.2. This new version requires new RBAC rules and some users set **nginx-ingress.rbac.create: false** to manage their own RBAC rules.\n\nThese users will need to add the RBAC rules before migrating to 1.11.2 or later. We added a fallback mechanism to only deploy 1.3.1 if this Helm value is set as above. We've also added **nginx-ingress.controller.image.disableFallback**, which defaults to false. Users who manage their own RBAC can set this to true to enable their deployments to also use 1.11.2, after ensuring the new RBAC rules are in place.\n\nWe plan to deprecate the 1.3.1 image support as well as the fallback mechanism as part of 17.5, so that we can remove this support completely and use only 1.11.2, which offers numerous security benefits.\n\n[Deprecation notice](https://docs.gitlab.com/update/deprecations/#fallback-support-for-gitlab-nginx-chart-controller-image-v131)\n\n**4. Application Security Testing analyzers major version update**\n\nGitLab.com | Self-Managed | Dedicated\n\nThe Application Security Testing stage will be bumping the major versions of its analyzers in tandem with the GitLab 18.0 release.\n\nIf you are not using the default included templates, or have pinned your analyzer versions, you must update your CI/CD job definition to either remove the pinned version or update the latest major version.\n\nUsers of GitLab 17.0-17.11 will continue to experience analyzer updates as normal until the release of GitLab 18.0. After GitLab 18.0, all newly fixed bugs and features will be released only in the new major version of the analyzers.\n\nWe do not backport bugs and features to deprecated versions as per our maintenance policy. As required, security patches will be backported to the latest three minor releases.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#application-security-testing-analyzers-major-version-update)\n\n**5. API Discovery will use branch pipelines by default**\n\nGitLab.com | Self-Managed | Dedicated\n\nIn GitLab 18.0, we'll update the default behavior of the CI/CD template for API Discovery (**API-Discovery.gitlab-ci.yml**).\n\nBefore GitLab 18.0, this template configures jobs to run in [**merge request pipelines**](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/) by default when an MR is open.\n\nStarting in GitLab 18.0, we'll align this template's behavior with the behavior of the [**Stable template editions**](https://docs.gitlab.com/user/application_security/detect/roll_out_security_scanning/#template-editions) for other AST scanners:\n\n* By default, the template will run scan jobs in branch pipelines.\n* You'll be able to set the CI/CD variable **AST_ENABLE_MR_PIPELINES: true** to use MR pipelines instead when an MR is open. The implementation of this new variable is tracked in [**Issue #410880**](https://gitlab.com/gitlab-org/gitlab/-/issues/410880).\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#api-discovery-will-use-branch-pipelines-by-default)\n\n**6. DAST DAST_DEVTOOLS_API_TIMEOUT will have a lower default value**\n\nGitLab.com | Self-Managed | Dedicated\n\nThe **DAST_DEVTOOLS_API_TIMEOUT** environment variable determines how long a DAST scan waits for a response from the browser. Before GitLab 18.0, the variable has a static value of 45 seconds. After GitLab 18.0, **DAST_DEVTOOLS_API_TIMEOUT** environment variable has a dynamic value, which is calculated based on other timeout configurations.\n\nIn most cases, the 45-second value was higher than the timeout value of many scanner functions. The dynamically calculated value makes the __DAST_DEVTOOLS_API_TIMEOUT__ variable more useful by increasing the number of cases to which it applies.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#dast-dast_devtools_api_timeout-will-have-a-lower-default-value)\n\n## Tools and resources to manage your impact\n\nWe’ve developed specific tooling to help our customers understand how these planned changes impact their GitLab instance(s). Once you’ve assessed your impact, we recommend reviewing the mitigation steps provided in the documentation to ensure a smooth transition to GitLab 18.0.\n\n* [Advanced Search Deprecations](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/deprecation-migration-tools/advanced-search-deprecations): This tool uses GitLab's Advanced Search API to find strings related to deprecations across GitLab groups and projects. It also reports which files should be manually checked. *__Note:__ May have some false positives.*\n* [Dependency Scanning Build Support Detection Helper](https://gitlab.com/security-products/tooling/build-support-detection-helper): This tool identifies projects impacted by three Dependency Scanning deprecations ([1](https://docs.gitlab.com/update/deprecations/#dependency-scanning-for-javascript-vendored-libraries), [2](https://docs.gitlab.com/update/deprecations/#dependency-scanning-upgrades-to-the-gitlab-sbom-vulnerability-scanner), [3](https://docs.gitlab.com/update/deprecations/#resolve-a-vulnerability-for-dependency-scanning-on-yarn-projects); all postponed to 19.0). It uses API to scan for relevant files and CI job names.\n* [GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md) (Self-Managed only): This experimental tool automatically checks a GitLab installation for known issues. It completes complex checks by looking at config files or database values. **Note:** Needs to run directly on your GitLab nodes.\n\nWe’ve also launched a series of micro courses (15 minutes or less!) on GitLab University to help you plan and execute mitigation activities for several of these changes. [Start your learning journey here](https://university.gitlab.com/catalog?query=18.0).\n\nIf you have a paid plan and have questions or require assistance with these changes, please [open a support ticket](https://support.gitlab.com/hc/en-us/articles/11626501035292-Support-Portal-User-Guide) on the GitLab Support Portal.\n\nIf you are a [free Gitlab.com user](https://support.gitlab.com/hc/en-us/articles/11625911285404-Statement-of-Support#free-users), you can access additional support through community sources, such as [GitLab Documentation](https://docs.gitlab.com/), [GitLab Community Forum](https://forum.gitlab.com/), and [Stack Overflow](http://stackoverflow.com/questions/tagged/gitlab).\n",[11,27],"DevSecOps platform","yml",{},true,"/en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"title":17,"description":18,"ogTitle":17,"ogDescription":18,"noIndex":14,"ogImage":23,"ogUrl":33,"ogSiteName":34,"ogType":35,"canonicalUrls":33},"https://about.gitlab.com/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0","https://about.gitlab.com","article","en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",[11,38],"devsecops-platform","vKL_VunJ5tt_5kvIrfiS8gqVZwZd0sYXRjdAsJ9E3co",{"data":41},{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":370,"minimal":401,"duo":420,"switchNav":429,"pricingDeployment":440},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/","gitlab logo","header",{"text":48,"config":49},"Get free trial",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"Talk to sales",{"href":55,"dataGaName":56,"dataGaLocation":46},"/sales/","sales",{"text":58,"config":59},"Sign in",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,90,185,190,291,351],{"text":64,"config":65,"cards":67},"Platform",{"dataNavLevelOne":66},"platform",[68,74,82],{"title":64,"description":69,"link":70},"The intelligent orchestration platform for DevSecOps",{"text":71,"config":72},"Explore our Platform",{"href":73,"dataGaName":66,"dataGaLocation":46},"/platform/",{"title":75,"description":76,"link":77},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":78,"config":79},"Meet GitLab Duo",{"href":80,"dataGaName":81,"dataGaLocation":46},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":83,"description":84,"link":85},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":86,"config":87},"Learn more",{"href":88,"dataGaName":89,"dataGaLocation":46},"/why-gitlab/","why gitlab",{"text":91,"left":30,"config":92,"link":94,"lists":98,"footer":167},"Product",{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"View all Solutions",{"href":97,"dataGaName":93,"dataGaLocation":46},"/solutions/",[99,123,146],{"title":100,"description":101,"link":102,"items":107},"Automation","CI/CD and automation to accelerate deployment",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":46},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,115,119],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":46,"dataGaName":109},"/solutions/continuous-integration/",{"text":75,"config":113},{"href":80,"dataGaLocation":46,"dataGaName":114},"gitlab duo agent platform - product menu",{"text":116,"config":117},"Source Code Management",{"href":118,"dataGaLocation":46,"dataGaName":116},"/solutions/source-code-management/",{"text":120,"config":121},"Automated Software Delivery",{"href":105,"dataGaLocation":46,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Security","Deliver code faster without compromising security",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":46,"icon":130},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[132,136,141],{"text":133,"config":134},"Application Security Testing",{"href":128,"dataGaName":135,"dataGaLocation":46},"Application security testing",{"text":137,"config":138},"Software Supply Chain Security",{"href":139,"dataGaLocation":46,"dataGaName":140},"/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Software Compliance",{"href":144,"dataGaName":145,"dataGaLocation":46},"/solutions/software-compliance/","software compliance",{"title":147,"link":148,"items":153},"Measurement",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":46},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[154,158,162],{"text":155,"config":156},"Visibility & Measurement",{"href":151,"dataGaLocation":46,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Value Stream Management",{"href":161,"dataGaLocation":46,"dataGaName":159},"/solutions/value-stream-management/",{"text":163,"config":164},"Analytics & Insights",{"href":165,"dataGaLocation":46,"dataGaName":166},"/solutions/analytics-and-insights/","Analytics and insights",{"title":168,"items":169},"GitLab for",[170,175,180],{"text":171,"config":172},"Enterprise",{"href":173,"dataGaLocation":46,"dataGaName":174},"/enterprise/","enterprise",{"text":176,"config":177},"Small Business",{"href":178,"dataGaLocation":46,"dataGaName":179},"/small-business/","small business",{"text":181,"config":182},"Public Sector",{"href":183,"dataGaLocation":46,"dataGaName":184},"/solutions/public-sector/","public sector",{"text":186,"config":187},"Pricing",{"href":188,"dataGaName":189,"dataGaLocation":46,"dataNavLevelOne":189},"/pricing/","pricing",{"text":191,"config":192,"link":194,"lists":198,"feature":278},"Resources",{"dataNavLevelOne":193},"resources",{"text":195,"config":196},"View all resources",{"href":197,"dataGaName":193,"dataGaLocation":46},"/resources/",[199,232,250],{"title":200,"items":201},"Getting started",[202,207,212,217,222,227],{"text":203,"config":204},"Install",{"href":205,"dataGaName":206,"dataGaLocation":46},"/install/","install",{"text":208,"config":209},"Quick start guides",{"href":210,"dataGaName":211,"dataGaLocation":46},"/get-started/","quick setup checklists",{"text":213,"config":214},"Learn",{"href":215,"dataGaLocation":46,"dataGaName":216},"https://university.gitlab.com/","learn",{"text":218,"config":219},"Product documentation",{"href":220,"dataGaName":221,"dataGaLocation":46},"https://docs.gitlab.com/","product documentation",{"text":223,"config":224},"Best practice videos",{"href":225,"dataGaName":226,"dataGaLocation":46},"/getting-started-videos/","best practice videos",{"text":228,"config":229},"Integrations",{"href":230,"dataGaName":231,"dataGaLocation":46},"/integrations/","integrations",{"title":233,"items":234},"Discover",[235,240,245],{"text":236,"config":237},"Customer success stories",{"href":238,"dataGaName":239,"dataGaLocation":46},"/customers/","customer success stories",{"text":241,"config":242},"Blog",{"href":243,"dataGaName":244,"dataGaLocation":46},"/blog/","blog",{"text":246,"config":247},"Remote",{"href":248,"dataGaName":249,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":251,"items":252},"Connect",[253,258,263,268,273],{"text":254,"config":255},"GitLab Services",{"href":256,"dataGaName":257,"dataGaLocation":46},"/services/","services",{"text":259,"config":260},"Community",{"href":261,"dataGaName":262,"dataGaLocation":46},"/community/","community",{"text":264,"config":265},"Forum",{"href":266,"dataGaName":267,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":269,"config":270},"Events",{"href":271,"dataGaName":272,"dataGaLocation":46},"/events/","events",{"text":274,"config":275},"Partners",{"href":276,"dataGaName":277,"dataGaLocation":46},"/partners/","partners",{"backgroundColor":279,"textColor":280,"text":281,"image":282,"link":286},"#2f2a6b","#fff","Insights for the future of software development",{"altText":283,"config":284},"the source promo card",{"src":285},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":287,"config":288},"Read the latest",{"href":289,"dataGaName":290,"dataGaLocation":46},"/the-source/","the source",{"text":292,"config":293,"lists":295},"Company",{"dataNavLevelOne":294},"company",[296],{"items":297},[298,303,309,311,316,321,326,331,336,341,346],{"text":299,"config":300},"About",{"href":301,"dataGaName":302,"dataGaLocation":46},"/company/","about",{"text":304,"config":305,"footerGa":308},"Jobs",{"href":306,"dataGaName":307,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":307},{"text":269,"config":310},{"href":271,"dataGaName":272,"dataGaLocation":46},{"text":312,"config":313},"Leadership",{"href":314,"dataGaName":315,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":317,"config":318},"Team",{"href":319,"dataGaName":320,"dataGaLocation":46},"/company/team/","team",{"text":322,"config":323},"Handbook",{"href":324,"dataGaName":325,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":327,"config":328},"Investor relations",{"href":329,"dataGaName":330,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":332,"config":333},"Trust Center",{"href":334,"dataGaName":335,"dataGaLocation":46},"/security/","trust center",{"text":337,"config":338},"AI Transparency Center",{"href":339,"dataGaName":340,"dataGaLocation":46},"/ai-transparency-center/","ai transparency center",{"text":342,"config":343},"Newsletter",{"href":344,"dataGaName":345,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":347,"config":348},"Press",{"href":349,"dataGaName":350,"dataGaLocation":46},"/press/","press",{"text":352,"config":353,"lists":354},"Contact us",{"dataNavLevelOne":294},[355],{"items":356},[357,360,365],{"text":53,"config":358},{"href":55,"dataGaName":359,"dataGaLocation":46},"talk to sales",{"text":361,"config":362},"Support portal",{"href":363,"dataGaName":364,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":366,"config":367},"Customer portal",{"href":368,"dataGaName":369,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":371,"login":372,"suggestions":379},"Close",{"text":373,"link":374},"To search repositories and projects, login to",{"text":375,"config":376},"gitlab.com",{"href":60,"dataGaName":377,"dataGaLocation":378},"search login","search",{"text":380,"default":381},"Suggestions",[382,384,388,390,394,398],{"text":75,"config":383},{"href":80,"dataGaName":75,"dataGaLocation":378},{"text":385,"config":386},"Code Suggestions (AI)",{"href":387,"dataGaName":385,"dataGaLocation":378},"/solutions/code-suggestions/",{"text":109,"config":389},{"href":111,"dataGaName":109,"dataGaLocation":378},{"text":391,"config":392},"GitLab on AWS",{"href":393,"dataGaName":391,"dataGaLocation":378},"/partners/technology-partners/aws/",{"text":395,"config":396},"GitLab on Google Cloud",{"href":397,"dataGaName":395,"dataGaLocation":378},"/partners/technology-partners/google-cloud-platform/",{"text":399,"config":400},"Why GitLab?",{"href":88,"dataGaName":399,"dataGaLocation":378},{"freeTrial":402,"mobileIcon":407,"desktopIcon":412,"secondaryButton":415},{"text":403,"config":404},"Start free trial",{"href":405,"dataGaName":51,"dataGaLocation":406},"https://gitlab.com/-/trials/new/","nav",{"altText":408,"config":409},"Gitlab Icon",{"src":410,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":408,"config":413},{"src":414,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":416,"config":417},"Get Started",{"href":418,"dataGaName":419,"dataGaLocation":406},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/get-started/","get started",{"freeTrial":421,"mobileIcon":425,"desktopIcon":427},{"text":422,"config":423},"Learn more about GitLab Duo",{"href":80,"dataGaName":424,"dataGaLocation":406},"gitlab duo",{"altText":408,"config":426},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":428},{"src":414,"dataGaName":411,"dataGaLocation":406},{"button":430,"mobileIcon":435,"desktopIcon":437},{"text":431,"config":432},"/switch",{"href":433,"dataGaName":434,"dataGaLocation":406},"#contact","switch",{"altText":408,"config":436},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":438},{"src":439,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":441,"mobileIcon":446,"desktopIcon":448},{"text":442,"config":443},"Back to pricing",{"href":188,"dataGaName":444,"dataGaLocation":406,"icon":445},"back to pricing","GoBack",{"altText":408,"config":447},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":449},{"src":414,"dataGaName":411,"dataGaLocation":406},{"title":451,"button":452,"config":457},"See how agentic AI transforms software delivery",{"text":453,"config":454},"Watch GitLab Transcend now",{"href":455,"dataGaName":456,"dataGaLocation":46},"/events/transcend/virtual/","transcend event",{"layout":458,"icon":459,"disabled":30},"release","AiStar",{"data":461},{"text":462,"source":463,"edit":469,"contribute":474,"config":479,"items":484,"minimal":690},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":464,"config":465},"View page source",{"href":466,"dataGaName":467,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":470,"config":471},"Edit this page",{"href":472,"dataGaName":473,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":475,"config":476},"Please contribute",{"href":477,"dataGaName":478,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":480,"facebook":481,"youtube":482,"linkedin":483},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[485,532,585,629,656],{"title":186,"links":486,"subMenu":501},[487,491,496],{"text":488,"config":489},"View plans",{"href":188,"dataGaName":490,"dataGaLocation":468},"view plans",{"text":492,"config":493},"Why Premium?",{"href":494,"dataGaName":495,"dataGaLocation":468},"/pricing/premium/","why premium",{"text":497,"config":498},"Why Ultimate?",{"href":499,"dataGaName":500,"dataGaLocation":468},"/pricing/ultimate/","why ultimate",[502],{"title":503,"links":504},"Contact Us",[505,508,510,512,517,522,527],{"text":506,"config":507},"Contact sales",{"href":55,"dataGaName":56,"dataGaLocation":468},{"text":361,"config":509},{"href":363,"dataGaName":364,"dataGaLocation":468},{"text":366,"config":511},{"href":368,"dataGaName":369,"dataGaLocation":468},{"text":513,"config":514},"Status",{"href":515,"dataGaName":516,"dataGaLocation":468},"https://status.gitlab.com/","status",{"text":518,"config":519},"Terms of use",{"href":520,"dataGaName":521,"dataGaLocation":468},"/terms/","terms of use",{"text":523,"config":524},"Privacy statement",{"href":525,"dataGaName":526,"dataGaLocation":468},"/privacy/","privacy statement",{"text":528,"config":529},"Cookie preferences",{"dataGaName":530,"dataGaLocation":468,"id":531,"isOneTrustButton":30},"cookie preferences","ot-sdk-btn",{"title":91,"links":533,"subMenu":541},[534,537],{"text":27,"config":535},{"href":73,"dataGaName":536,"dataGaLocation":468},"devsecops platform",{"text":538,"config":539},"AI-Assisted Development",{"href":80,"dataGaName":540,"dataGaLocation":468},"ai-assisted development",[542],{"title":543,"links":544},"Topics",[545,550,555,560,565,570,575,580],{"text":546,"config":547},"CICD",{"href":548,"dataGaName":549,"dataGaLocation":468},"/topics/ci-cd/","cicd",{"text":551,"config":552},"GitOps",{"href":553,"dataGaName":554,"dataGaLocation":468},"/topics/gitops/","gitops",{"text":556,"config":557},"DevOps",{"href":558,"dataGaName":559,"dataGaLocation":468},"/topics/devops/","devops",{"text":561,"config":562},"Version Control",{"href":563,"dataGaName":564,"dataGaLocation":468},"/topics/version-control/","version control",{"text":566,"config":567},"DevSecOps",{"href":568,"dataGaName":569,"dataGaLocation":468},"/topics/devsecops/","devsecops",{"text":571,"config":572},"Cloud Native",{"href":573,"dataGaName":574,"dataGaLocation":468},"/topics/cloud-native/","cloud native",{"text":576,"config":577},"AI for Coding",{"href":578,"dataGaName":579,"dataGaLocation":468},"/topics/devops/ai-for-coding/","ai for coding",{"text":581,"config":582},"Agentic AI",{"href":583,"dataGaName":584,"dataGaLocation":468},"/topics/agentic-ai/","agentic ai",{"title":586,"links":587},"Solutions",[588,590,592,597,601,604,608,611,613,616,619,624],{"text":133,"config":589},{"href":128,"dataGaName":133,"dataGaLocation":468},{"text":122,"config":591},{"href":105,"dataGaName":106,"dataGaLocation":468},{"text":593,"config":594},"Agile development",{"href":595,"dataGaName":596,"dataGaLocation":468},"/solutions/agile-delivery/","agile delivery",{"text":598,"config":599},"SCM",{"href":118,"dataGaName":600,"dataGaLocation":468},"source code management",{"text":546,"config":602},{"href":111,"dataGaName":603,"dataGaLocation":468},"continuous integration & delivery",{"text":605,"config":606},"Value stream management",{"href":161,"dataGaName":607,"dataGaLocation":468},"value stream management",{"text":551,"config":609},{"href":610,"dataGaName":554,"dataGaLocation":468},"/solutions/gitops/",{"text":171,"config":612},{"href":173,"dataGaName":174,"dataGaLocation":468},{"text":614,"config":615},"Small business",{"href":178,"dataGaName":179,"dataGaLocation":468},{"text":617,"config":618},"Public sector",{"href":183,"dataGaName":184,"dataGaLocation":468},{"text":620,"config":621},"Education",{"href":622,"dataGaName":623,"dataGaLocation":468},"/solutions/education/","education",{"text":625,"config":626},"Financial services",{"href":627,"dataGaName":628,"dataGaLocation":468},"/solutions/finance/","financial services",{"title":191,"links":630},[631,633,635,637,640,642,644,646,648,650,652,654],{"text":203,"config":632},{"href":205,"dataGaName":206,"dataGaLocation":468},{"text":208,"config":634},{"href":210,"dataGaName":211,"dataGaLocation":468},{"text":213,"config":636},{"href":215,"dataGaName":216,"dataGaLocation":468},{"text":218,"config":638},{"href":220,"dataGaName":639,"dataGaLocation":468},"docs",{"text":241,"config":641},{"href":243,"dataGaName":244,"dataGaLocation":468},{"text":236,"config":643},{"href":238,"dataGaName":239,"dataGaLocation":468},{"text":246,"config":645},{"href":248,"dataGaName":249,"dataGaLocation":468},{"text":254,"config":647},{"href":256,"dataGaName":257,"dataGaLocation":468},{"text":259,"config":649},{"href":261,"dataGaName":262,"dataGaLocation":468},{"text":264,"config":651},{"href":266,"dataGaName":267,"dataGaLocation":468},{"text":269,"config":653},{"href":271,"dataGaName":272,"dataGaLocation":468},{"text":274,"config":655},{"href":276,"dataGaName":277,"dataGaLocation":468},{"title":292,"links":657},[658,660,662,664,666,668,670,674,679,681,683,685],{"text":299,"config":659},{"href":301,"dataGaName":294,"dataGaLocation":468},{"text":304,"config":661},{"href":306,"dataGaName":307,"dataGaLocation":468},{"text":312,"config":663},{"href":314,"dataGaName":315,"dataGaLocation":468},{"text":317,"config":665},{"href":319,"dataGaName":320,"dataGaLocation":468},{"text":322,"config":667},{"href":324,"dataGaName":325,"dataGaLocation":468},{"text":327,"config":669},{"href":329,"dataGaName":330,"dataGaLocation":468},{"text":671,"config":672},"Sustainability",{"href":673,"dataGaName":671,"dataGaLocation":468},"/sustainability/",{"text":675,"config":676},"Diversity, inclusion and belonging (DIB)",{"href":677,"dataGaName":678,"dataGaLocation":468},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":332,"config":680},{"href":334,"dataGaName":335,"dataGaLocation":468},{"text":342,"config":682},{"href":344,"dataGaName":345,"dataGaLocation":468},{"text":347,"config":684},{"href":349,"dataGaName":350,"dataGaLocation":468},{"text":686,"config":687},"Modern Slavery Transparency Statement",{"href":688,"dataGaName":689,"dataGaLocation":468},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":691},[692,695,698],{"text":693,"config":694},"Terms",{"href":520,"dataGaName":521,"dataGaLocation":468},{"text":696,"config":697},"Cookies",{"dataGaName":530,"dataGaLocation":468,"id":531,"isOneTrustButton":30},{"text":699,"config":700},"Privacy",{"href":525,"dataGaName":526,"dataGaLocation":468},[702,716,728],{"id":703,"title":704,"body":10,"config":705,"content":707,"description":10,"extension":28,"meta":711,"navigation":30,"path":712,"seo":713,"stem":714,"__hash__":715},"blogAuthors/en-us/blog/authors/martin-brmmer.yml","Martin Brmmer",{"template":706},"BlogAuthor",{"name":20,"config":708},{"headshot":709,"ctfId":710},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659427/Blog/Author%20Headshots/martin_brummer.webp","1QkLKK0UnkvZDDBzzEhkaA",{},"/en-us/blog/authors/martin-brmmer",{},"en-us/blog/authors/martin-brmmer","5XXFf9xKfqhpm33ots964Z5lLGWP6fmjjylRLOrvUe4",{"id":717,"title":21,"body":10,"config":718,"content":719,"description":10,"extension":28,"meta":723,"navigation":30,"path":724,"seo":725,"stem":726,"__hash__":727},"blogAuthors/en-us/blog/authors/fabian-zimmer.yml",{"template":706},{"name":21,"config":720},{"headshot":721,"ctfId":722},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750713473/q6awwqbxtg0a4x9gtmhs.png","3TK88UogcX5lx83kWMVuvI",{},"/en-us/blog/authors/fabian-zimmer",{},"en-us/blog/authors/fabian-zimmer","qPVb4mKZuBff6-yly4-T5Bar6IdyXcx_tJHGlSL8QIA",{"id":729,"title":22,"body":10,"config":730,"content":731,"description":10,"extension":28,"meta":735,"navigation":30,"path":736,"seo":737,"stem":738,"__hash__":739},"blogAuthors/en-us/blog/authors/sam-wiskow.yml",{"template":706},{"name":22,"config":732},{"headshot":733,"ctfId":734},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659433/Blog/Author%20Headshots/swiskow-headshot.jpg","swiskow",{},"/en-us/blog/authors/sam-wiskow",{},"en-us/blog/authors/sam-wiskow","TR52XmFI8G3xfSF6pTXW6r_bf0Bd5tf82MmM7VjjKfM",[741,752,766],{"content":742,"config":750},{"title":743,"description":744,"heroImage":745,"date":746,"category":11,"tags":747},"GitLab Patch Release: 18.10.3, 18.9.5, 18.8.9","Learn more this patch release for GitLab Community Edition and Enterprise Edition.\n\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg","2026-04-08",[748,749],"security releases","patch releases",{"featured":14,"template":15,"externalUrl":751},"https://about.gitlab.com/releases/2026/04/08/patch-release-gitlab-18-10-3-released/",{"content":753,"config":764},{"title":754,"description":755,"heroImage":756,"category":11,"tags":757,"authors":759,"date":762,"body":763},"Streamline test management with the SmartBear QMetry GitLab component","Learn how to automatically upload test results from GitLab CI/CD pipelines to SmartBear QMetry Test Management Enterprise using the CI/CD Catalog component.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1775486753/cswmwtygkgkbdsibo09v.png",[758,11,559],"tutorial",[760,761],"Matt Genelin","Matt Bonner","2026-04-07","In modern software development, test management and continuous integration are two sides of the same coin. DevSecOps teams need seamless integration between their CI/CD pipelines and test management platforms to maintain visibility, traceability, and compliance across the software development lifecycle.\n\nThis becomes even more important as testing scales across automated pipelines, where execution data is spread across tools and harder to track in one place.\n\nFor organizations using GitLab for CI/CD and SmartBear QMetry for test management, manually uploading test results creates friction, delays feedback loops, and makes it harder to maintain a reliable, centralized view of testing.\n\nWhat if you could automatically publish your JUnit, TestNG, or other test results directly from your GitLab pipeline to QMetry with just a few lines of configuration?\n\nThat's exactly what the new **QMetry GitLab Component** enables. This reusable CI/CD component, now available in the [GitLab CI/CD Catalog](https://gitlab.com/explore/catalog), eliminates the manual overhead of test result management by automatically uploading test execution data to QMetry.  This is an AI-enabled, enterprise-grade test management platform that brings together test planning, execution, tracking, and reporting in one place.\n\nAs a centralized system of record for testing, QMetry helps teams understand coverage, track execution, and make more reliable release decisions.\n\nIn this guide, you'll learn:\n\n* How to set up the QMetry GitLab Component in your pipeline  \n* How to configure automated test result uploads  \n* Advanced configuration options for enterprise requirements  \n* A real-world aerospace industry use case  \n* Best practices for test management automation\n\nBy the end of this article, your GitLab pipelines will automatically feed test results into QMetry, giving your QA teams instant visibility into test execution and helping them make faster, more confident release decisions.\n\n![SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/ojt707rzxnm2yr3vqxdh.png)\n\n## Why integrate GitLab with QMetry?\n\nBefore diving into the technical implementation, let's understand the value this integration delivers:\n\n### Eliminate manual test result uploads\n\nDevSecOps engineers and QA teams no longer need to manually export test results from CI/CD runs and import them into test management systems. The component handles this automatically after every pipeline execution.\n\nThis reduces manual effort while ensuring test data stays consistent, up to date, and easy to access across teams.\n\n![Test results with SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/ajx64sihup2nursdpnxz.png)\n\n### Enable end-to-end traceability\n\nBy connecting GitLab's CI/CD execution data with QMetry's test management capabilities, teams gain complete traceability from requirements through test cases to actual test execution results. This is critical for regulated industries like financial services, aerospace, medical devices, and automotive, where audit trails are mandatory and regulatory compliance depends on demonstrating complete test coverage.\n\nIt also gives teams a clearer view of coverage and risk across releases, making it easier to understand what’s been tested and what still needs attention.\n\n### Accelerate feedback loops\n\nAutomated test result uploads mean QA teams, product managers, and stakeholders see test execution results immediately after pipeline completion – no waiting for manual data entry or report generation.\n\nWith faster access to results, teams can act immediately, reduce delays, and make quicker, more informed release decisions.\n\n### Support compliance and audit requirements\n\nFor organizations in regulated industries, maintaining comprehensive test records with proper versioning and traceability is non-negotiable. This integration ensures you can document every test execution properly in QMetry with links back to the specific GitLab pipeline, commit, and build.\n\nThis creates an audit-ready record of testing activity without adding manual overhead.\n\n![Audit-ready record of testing with SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/q2tbaw5otgdywjkcquqx.png)\n\n### Leverage AI-powered test insights\n\nQMetry uses AI to analyze test execution patterns, identify flaky tests, predict test failures, and recommend optimization opportunities. Feeding it real-time data from GitLab pipelines maximizes the value of these AI capabilities.\n\nWith continuous data flowing in, teams get more accurate insights and can focus their efforts where it matters most.\n\n![Accurage insights with SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/pl7ru4wx8ixnheedfyrs.png)\n\n## About the GitLab and SmartBear partnership\n\nThis component represents a growing partnership between GitLab and SmartBear to better connect CI/CD execution with test management in a single workflow. SmartBear brings deep expertise in testing, API management, and quality automation, while GitLab provides the most comprehensive AI-powered DevSecOps platform. Together, they help teams streamline how testing fits into the development lifecycle while maintaining the quality, security, and compliance standards their industries require.\n\nWhether you're managing test execution for aerospace flight control systems, financial services platforms, automotive safety applications, or medical device software, the combination of GitLab's CI/CD capabilities and QMetry's test management gives teams a centralized, reliable view of testing across the lifecycle, helping them track execution, maintain traceability, and make more confident release decisions.\n\n## What you'll need\n\nBefore getting started, ensure you have:\n\n* **A GitLab account** with a project containing automated tests that generate test result files (JUnit XML, TestNG XML, etc.)  \n* **QMetry Test Management Enterprise** account with API access enabled  \n* **QMetry API Key** generated  from your QMetry instance (we'll cover this shortly)  \n* **QMetry Project** already created where you will upload test results   \n* **Familiarity with GitLab CI/CD**, including understanding of basic `.gitlab-ci.yml` syntax and pipeline concepts  \n* **Test suite configuration** in QMetry (optional but recommended for better organization)\n\n### Understanding the test result flow\n\nHere's what happens when you integrate this component:\n\n1. **Test execution**: Your GitLab CI/CD pipeline runs automated tests (unit tests, integration tests, E2E tests, etc.).  \n2. **Result generation**: Tests produce output files in formats like JUnit XML, TestNG XML, or other supported formats.  \n3. **Component invocation**: The QMetry component executes as a job in your pipeline.  \n4. **Automatic upload**: The component reads your test result files and uploads them to QMetry via API.  \n5. **QMetry processing**: QMetry receives the results, processes them, and makes them available for reporting and analysis.\n\nThe beauty of this integration is that it happens automatically, with no manual intervention required once configured.\n\n## Part 1: Getting your QMetry API credentials\n\nBefore configuring the GitLab component, you need to obtain API access credentials from your QMetry instance. Here are the steps to follow:\n\n### 1. Access QMetry settings\n\n1. Log in to your **QMetry Test Management Enterprise** instance.  \n2. Navigate to your **user profile** (typically in the top-right corner).  \n3. Select **Settings** or **API Access** from the dropdown menu.\n\n### 2. Generate an API key\n\n1. In the API Access section, click **Generate New API Key.**  \n2. Provide a descriptive **name** for the key (e.g., \"GitLab CI/CD Integration\").  \n3. Set appropriate **permissions**. The key needs write access to upload test results.  \n4. Click **Generate.**  \n5. **Copy the API key immediately** as it will only be displayed once.\n\n**Important security note**: Treat your API key like a password. Never commit it directly to your `.gitlab-ci.yml` file or store it in plain text. We'll use GitLab CI/CD variables to store it securely.\n\n### 3. Note your QMetry instance URL\n\nYou'll also need your QMetry instance URL, which typically follows this format:\n\n```text\nhttps://your-company.qmetry.com\n```\n\nor, for self-hosted instances:\n\n```text\nhttps://qmetry.your-company.com\n```\n\nMake note of this URL because you'll need it in the next section.\n\n## Part 2: Configuring GitLab CI/CD variables\n\nNow that you have your QMetry credentials, let's store them securely in GitLab. Here are the next steps to follow:\n\n### 4. Navigate to CI/CD settings\n\n1. Open your **GitLab project.**  \n2. In the left sidebar, navigate to **Settings > CI/CD.**  \n3. Expand the **Variables** section.  \n4. Click **Add variable.**\n\n### 5. Add the QMetry API key\n\nConfigure the API key variable:\n\n| Field | Value |\n| ----- | ----- |\n| **Key** | `QMETRY_API_KEY` |\n| **Value** | Your QMetry API key from Step 2 |\n| **Type** | Variable |\n| **Flags** | ✅ Mask variable\u003Cbr>✅ Protect variable (recommended) |\n\nClick **Add variable** to save.\n\n### 6. Add the QMetry instance URL\n\nAdd a second variable for your instance URL:\n\n| Field | Value |\n| ----- | ----- |\n| **Key** | `INSTANCE_URL` |\n| **Value** | Your QMetry instance URL (e.g., `https://your-company.qmetry.com`) |\n| **Type** | Variable |\n| **Flags** | (optional: Protect variable) |\n\nClick **Add variable** to save.\n\n**Why use CI/CD variables?**\n\n* **Security**: Masked variables are hidden in job logs.  \n* **Reusability**: You can use the same credentials across multiple pipelines.  \n* **Flexibility**: It is easy to rotate credentials without modifying pipeline code.  \n* **Access control**: Protected variables are only available on protected branches.\n\n## Part 3: Understanding your test result files\n\nBefore integrating the component, ensure your tests generate output files that QMetry can process. Here are the next steps to follow:\n\n### 7. Verify test output format\n\nThe QMetry component supports multiple test result formats. The most common is **JUnit XML**, which most testing frameworks can generate:\n\n**Example JUnit XML output** (`results.xml`):\n\n```xml\n\u003C?xml version=\"1.0\" encoding=\"UTF-8\"?>\n\u003Ctestsuites>\n  \u003Ctestsuite name=\"Flight Control System Tests\" tests=\"15\" failures=\"1\" errors=\"0\" time=\"45.231\">\n    \u003Ctestcase classname=\"FlightControlTests\" name=\"testAltitudeHold\" time=\"2.341\">\n      \u003Csystem-out>Altitude hold engaged at 10,000 feet\u003C/system-out>\n    \u003C/testcase>\n    \u003Ctestcase classname=\"FlightControlTests\" name=\"testAutopilotEngagement\" time=\"3.125\">\n      \u003Csystem-out>Autopilot engaged successfully\u003C/system-out>\n    \u003C/testcase>\n    \u003Ctestcase classname=\"FlightControlTests\" name=\"testEmergencyLanding\" time=\"5.892\">\n      \u003Cfailure message=\"Landing gear failed to deploy\">\n        Expected: Landing gear deployed\n        Actual: Landing gear malfunction detected\n      \u003C/failure>\n    \u003C/testcase>\n    \u003C!-- Additional test cases... -->\n  \u003C/testsuite>\n\u003C/testsuites>\n```\n\nMost testing frameworks generate this format automatically:\n\n* **JUnit** (Java): Native format  \n* **pytest** (Python): Use `--junitxml=results.xml` flag  \n* **Jest** (JavaScript): Use `jest-junit` reporter  \n* **RSpec** (Ruby): Use `rspec_junit_formatter`  \n* **NUnit** (.NET): Use `nunit-console` with XML output  \n* **Go test**: Use `go-junit-report`\n\n### 8. Confirm test artifact configuration\n\nEnsure your existing pipeline saves test results as **artifacts**. This allows the QMetry component to access them:\n\n```yaml\ntest:\n  stage: test\n  script:\n    - npm install\n    - npm test -- --reporter=junit --reporter-options=output=results.xml\n  artifacts:\n    reports:\n      junit: results.xml\n    paths:\n      - results.xml\n    when: always  # Upload even if tests fail\n```\n\n**Key points**:\n\n* `artifacts.reports.junit` makes results visible in GitLab's test report UI.  \n* `artifacts.paths` ensures the file is available to downstream jobs.  \n* `when: always` ensures results upload even if tests fail.\n\n## Part 4: Integrating the QMetry component\n\nNow for the main event – adding the QMetry component to your pipeline. Here are the next steps to follow:\n\n### 9. Basic component integration\n\nAdd the component to your `.gitlab-ci.yml` file. The component should run **after** your tests complete:\n\n```yaml\ninclude:\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: test\n      project: \"Aerospace Flight Control System\"\n      file_name: \"results.xml\"\n      testing_type: \"JUNIT\"\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n```\n\nLet's break down each input parameter:\n\n| Parameter | Description | Example |\n| ----- | ----- | ----- |\n| `stage` | Which CI/CD stage runs the upload job | `test` |\n| `project` | Your QMetry project name or key | `\"Aerospace Flight Control System\"` |\n| `file_name` | Path to your test results file | `\"results.xml\"` |\n| `testing_type` | Format of your test results | `\"JUNIT\"` (also supports: `TESTNG`, `NUNIT`, etc.) |\n| `instance_url` | Your QMetry instance URL | `${INSTANCE_URL}` (from CI/CD variables) |\n| `api_key` | QMetry API key for authentication | `${QMETRY_API_KEY}` (from CI/CD variables) |\n\n### 10. Complete pipeline example\n\nHere's a complete `.gitlab-ci.yml` example showing test execution followed by QMetry upload:\n\n```yaml\nstages:\n  - test\n  - report\n\nvariables:\n  # Your app-specific variables\n  NODE_VERSION: \"18\"\n\n# Run your automated tests\nunit-tests:\n  stage: test\n  image: node:${NODE_VERSION}\n  script:\n    - npm ci\n    - npm run test:unit -- --reporter=junit --reporter-options=output=results.xml\n  artifacts:\n    reports:\n      junit: results.xml\n    paths:\n      - results.xml\n    when: always\n  tags:\n    - docker\n\n# Upload results to QMetry\ninclude:\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: test  # Runs in same stage as tests\n      project: \"Aerospace Flight Control System\"\n      file_name: \"results.xml\"\n      testing_type: \"JUNIT\"\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n```\n\n### 11. Run your pipeline\n\nCommit and push your changes:\n\n```shell\ngit add .gitlab-ci.yml\ngit commit -m \"Add QMetry test result integration\"\ngit push origin main\n```\n\nNavigate to your GitLab project's **CI/CD > Pipelines** to watch the execution.\n\n### 12. Verify successful upload\n\nAfter the pipeline completes, you should see:\n\n**In GitLab**:\n\n1. A new job in your pipeline named `qmetry-import` (or similar)  \n2. Job logs showing successful API communication  \n3. Green checkmark indicating successful upload\n\n**Example successful job log**:\n\n```json\n$ curl -X POST https://your-company.qmetry.com/api/v3/test-results/import \\\n  -H \"Authorization: Bearer ${QMETRY_API_KEY}\" \\\n  -H \"Content-Type: application/json\" \\\n  -d @payload.json\n\n{\n  \"status\": \"success\",\n  \"message\": \"Test results uploaded successfully\",\n  \"results_processed\": 15,\n  \"test_cases_created\": 3,\n  \"test_cases_updated\": 12,\n  \"execution_id\": \"EXE-12345\"\n}\n\nJob succeeded ```\n\n**In QMetry**:\n\n1. Navigate to your project dashboard.  \n2. Check the **Test Executions** section.  \n3. You should see a new test execution with results from your GitLab pipeline.  \n4. Click into the execution to see detailed test case results.\n\n\n## Part 5: Advanced configuration options\n\nNow that you have the basic integration working, let's explore advanced configuration for enterprise requirements. Here are the next steps to follow:\n\n### 13. Organizing results with test suites\n\nFor better organization, you can specify which QMetry test suite should receive results:\n\n```yaml\ninclude:\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: test\n      project: \"Aerospace Flight Control System\"\n      file_name: \"results.xml\"\n      testing_type: \"JUNIT\"\n      testsuite_name: \"Sprint 23 Regression Tests\"\n      testsuite_id: \"TS-456\"  # Optional: Use existing test suite ID\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n```\n\n**When to use test suites**:\n\n* Organizing tests by sprint or release  \n* Separating regression tests from new feature tests  \n* Grouping tests by component or subsystem  \n* Creating test execution hierarchies for reporting\n\n### 14. Configuring automation hierarchy levels\n\nQMetry supports hierarchical test organization. Use the `automation_hierarchy` parameter to specify the organization level:\n\n```yaml\ninclude:\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: test\n      project: \"Aerospace Flight Control System\"\n      file_name: \"results.xml\"\n      testing_type: \"JUNIT\"\n      automation_hierarchy: \"2\"  # Level 2 hierarchy\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n```\n\n**Hierarchy levels explained**:\n\n* **Level 1**: Top-level test suites (e.g., \"All Regression Tests\")  \n* **Level 2**: Sub-suites (e.g., \"Flight Control Tests\" under \"Regression Tests\")  \n* **Level 3**: Granular test groups (e.g., \"Altitude Hold Tests\" under \"Flight Control\")\n\n### 15. Multiple test result files\n\nFor complex projects with multiple test jobs, you can invoke the component multiple times:\n\n```yaml\nstages:\n  - test\n\n# Unit tests\nunit-tests:\n  stage: test\n  script:\n    - npm run test:unit\n  artifacts:\n    paths:\n      - unit-results.xml\n    when: always\n\n# Integration tests\nintegration-tests:\n  stage: test\n  script:\n    - npm run test:integration\n  artifacts:\n    paths:\n      - integration-results.xml\n    when: always\n\n# Upload unit test results\ninclude:\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: test\n      project: \"Aerospace Flight Control System\"\n      file_name: \"unit-results.xml\"\n      testing_type: \"JUNIT\"\n      testsuite_name: \"Unit Tests - Sprint 23\"\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n\n  # Upload integration test results\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: test\n      project: \"Aerospace Flight Control System\"\n      file_name: \"integration-results.xml\"\n      testing_type: \"JUNIT\"\n      testsuite_name: \"Integration Tests - Sprint 23\"\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n```\n\n### 16. Custom runner tags\n\nFor enterprise environments with dedicated runners, specify runner tags:\n\n```yaml\ninclude:\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: test\n      runner_tag: \"production-runners\"  # Use specific runner pool\n      project: \"Aerospace Flight Control System\"\n      file_name: \"results.xml\"\n      testing_type: \"JUNIT\"\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n```\n\n### 17. Custom test suite folders\n\nOrganize test suites into folders for better project structure:\n\n```yaml\ninclude:\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: test\n      project: \"Aerospace Flight Control System\"\n      file_name: \"results.xml\"\n      testing_type: \"JUNIT\"\n      testsuite_folder_path: \"/Regression/Sprint-23/Flight-Controls\"\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n```\n\nThis creates a folder hierarchy in QMetry:\n\n```none\nAerospace Flight Control System/\n└── Regression/\n    └── Sprint-23/\n        └── Flight-Controls/\n            └── [Your test execution]\n```\n\n### 18. Advanced field mapping\n\nFor enterprise QMetry instances with custom fields, use the `testcase_fields` and `testsuite_fields` parameters:\n\n```yaml\ninclude:\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: test\n      project: \"Aerospace Flight Control System\"\n      file_name: \"results.xml\"\n      testing_type: \"JUNIT\"\n      testcase_fields: \"priority=P1,component=FlightControl,certification=DO-178C\"\n      testsuite_fields: \"release=v2.4.0,sprint=23\"\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n```\n\nThis adds custom metadata to test cases and suites for enhanced filtering and reporting.\n\n## Part 6: Real-world use cases\n\nLet's explore how organizations across different industries are using this integration to solve critical quality and compliance challenges.\n\n### Financial services: Enterprise banking platforms\n\nLeading financial institutions are evolving their engineering practices with integrated DevOps platforms. These organizations face unique challenges when managing test automation at scale.\n\n**The challenge for financial services**:\n\n* **Regulatory compliance**: Financial services must maintain detailed audit trails for all testing activities.  \n* **Multiple compliance frameworks**: Firms must adhere to FCA, PSD2, GDPR, and internal risk management policies.  \n* **High-frequency deployments**: Multiple production deployments are required daily across microservices.  \n* **Zero-tolerance for failures**: Banking systems require extremely high reliability.  \n* **Distributed teams**: QA teams need real-time visibility across global engineering teams.\n\n**The solution**: Financial services organizations implementing the QMetry GitLab Component can automate test result uploads across their CI/CD pipelines for:\n\n* Unit tests for hundreds of microservices  \n* API contract tests for inter-service communication  \n* End-to-end transaction flow tests  \n* Security and compliance scanning results  \n* Performance and load testing results\n\n**Example implementation approach**:\n\n```yaml\n# Financial services approach: Separate test uploads by test type\nstages:\n  - test\n  - security\n  - report\n\n# Unit tests for payment processing service\nunit-tests:\n  stage: test\n  script:\n    - mvn clean test\n  artifacts:\n    paths:\n      - target/surefire-reports/TEST-*.xml\n    when: always\n\n# Upload to QMetry with compliance metadata\ninclude:\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: report\n      project: \"Payment Processing Platform\"\n      file_name: \"target/surefire-reports/TEST-*.xml\"\n      testing_type: \"JUNIT\"\n      testsuite_name: \"Payment Services - Unit Tests\"\n      testsuite_folder_path: \"/Regulatory/FCA-Compliance/Unit-Tests\"\n      testcase_fields: \"compliance=FCA,risk_level=high,service=payments\"\n      automation_hierarchy: \"2\"\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n```\n\n**Potential business outcomes for financial services**:\n\n* **Significant reduction** in manual test reporting time  \n* **Complete audit trail coverage** for regulatory reviews  \n* **Real-time visibility** for distributed QA teams  \n* **Faster time-to-production** with automated quality gates  \n* **Enhanced compliance posture** with complete traceability from requirements to test execution\n\n### Aerospace flight control testing\n\nLet's explore how an aerospace company might use this integration for critical flight control system testing.\n\n**Aerospace software development faces unique requirements and challenges:**\n\n* **DO-178C compliance**: Aviation software must follow strict certification standards  \n* **Complete traceability**: Every requirement must link to test cases and execution results  \n* **Audit trails**: Regulators require detailed records of all testing activities  \n* **Safety-critical quality**: Failures can have catastrophic consequences  \n* **Multiple test levels**: Unit, integration, system, and certification tests\n\n**The solution:** By integrating GitLab CI/CD with QMetry, the aerospace engineering team achieves automated test execution and reporting.\n\n\n```yaml\nstages:\n  - build\n  - unit-test\n  - integration-test\n  - system-test\n  - report\n\n# Build flight control firmware\nbuild-firmware:\n  stage: build\n  script:\n    - make clean\n    - make build TARGET=flight-control\n  artifacts:\n    paths:\n      - build/flight-control.bin\n\n# Unit tests (DO-178C Level A)\nunit-tests:\n  stage: unit-test\n  script:\n    - make test-unit OUTPUT=junit\n  artifacts:\n    paths:\n      - test-results/unit-tests.xml\n    when: always\n\n# Hardware-in-the-loop integration tests\nhil-integration-tests:\n  stage: integration-test\n  tags:\n    - hil-test-bench  # Dedicated hardware test environment\n  script:\n    - ./scripts/deploy-to-test-bench.sh\n    - ./scripts/run-hil-tests.sh\n  artifacts:\n    paths:\n      - test-results/hil-tests.xml\n    when: always\n\n# System-level certification tests\ncertification-tests:\n  stage: system-test\n  tags:\n    - certification-environment\n  script:\n    - ./scripts/run-certification-suite.sh\n  artifacts:\n    paths:\n      - test-results/certification-tests.xml\n    when: always\n  only:\n    - main  # Only run on main branch\n\n# Upload unit test results to QMetry\ninclude:\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: report\n      project: \"Flight Control System v2.4\"\n      file_name: \"test-results/unit-tests.xml\"\n      testing_type: \"JUNIT\"\n      testsuite_name: \"Unit Tests - DO-178C Level A\"\n      testsuite_folder_path: \"/Certification/DO-178C/Unit\"\n      testcase_fields: \"compliance=DO-178C,level=A,safety_critical=true\"\n      automation_hierarchy: \"2\"\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n\n  # Upload HIL test results\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: report\n      project: \"Flight Control System v2.4\"\n      file_name: \"test-results/hil-tests.xml\"\n      testing_type: \"JUNIT\"\n      testsuite_name: \"Hardware-in-Loop Integration Tests\"\n      testsuite_folder_path: \"/Certification/DO-178C/Integration\"\n      testcase_fields: \"compliance=DO-178C,level=A,test_type=HIL\"\n      automation_hierarchy: \"2\"\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n\n  # Upload certification test results\n  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n    inputs:\n      stage: report\n      project: \"Flight Control System v2.4\"\n      file_name: \"test-results/certification-tests.xml\"\n      testing_type: \"JUNIT\"\n      testsuite_name: \"System Certification Tests\"\n      testsuite_folder_path: \"/Certification/DO-178C/System\"\n      testcase_fields: \"compliance=DO-178C,level=A,certification_ready=true\"\n      automation_hierarchy: \"1\"\n      instance_url: ${INSTANCE_URL}\n      api_key: ${QMETRY_API_KEY}\n```\n\n### The results\n\n**Before integration**:\n\n* QA engineers manually exported test results from GitLab  \n* Imported results into QMetry through UI uploads  \n* Process took 2-3 hours per test cycle  \n* Human error risk in data entry  \n* Delayed feedback to stakeholders\n\n**After integration**:\n\n* Test results automatically flow from GitLab to QMetry  \n* Complete audit trail from commit → test → result  \n* Zero manual intervention required  \n* Real-time visibility for certification auditors  \n* Compliance reports generated automatically\n\n**Example QMetry dashboard after integration**:\n\n```none\n╔════════════════════════════════════════════════════════════╗\n║  Flight Control System v2.4 - Test Execution Dashboard     ║\n╠════════════════════════════════════════════════════════════╣\n║                                                            ║\n║  📊 Test Execution Summary (Last 7 Days)                   ║\n║  ───────────────────────────────────────────────────────── ║\n║  ✓ Total Tests Executed: 1,247                             ║\n║  ✓ Passed: 1,241 (99.5%)                                   ║\n║  ✗ Failed: 6 (0.5%)                                        ║\n║  ⏸ Skipped: 0                                              ║\n║                                                            ║\n║  📁 Test Suite Organization                                ║\n║  ───────────────────────────────────────────────────────── ║\n║  └─ Certification/                                         ║\n║     └─ DO-178C/                                            ║\n║        ├─ Unit/ (487 tests, 100% pass)                     ║\n║        ├─ Integration/ (623 tests, 99.2% pass)             ║\n║        └─ System/ (137 tests, 100% pass)                   ║\n║                                                            ║\n║  🔗 Traceability                                           ║\n║  ───────────────────────────────────────────────────────── ║\n║  Requirements Covered: 342/342 (100%)                      ║\n║  Test Cases Linked: 1,247/1,247 (100%)                     ║\n║  GitLab Pipeline Executions: 47 (automated)                ║\n║                                                            ║\n║  ⚠️  Action Items                                          ║\n║  ───────────────────────────────────────────────────────── ║\n║  • 6 failed tests require investigation                    ║\n║  • Last execution: 2 minutes ago (Pipeline #1543)          ║\n║  • GitLab Commit: a7f8c23 \"Fix altitude hold logic\"        ║\n║                                                            ║\n╚════════════════════════════════════════════════════════════╝\n```\n\n### Compliance and audit benefits\n\nBoth financial services and aerospace organizations can leverage this integration for compliance:\n\n**For financial services (FCA, PSD2, SOX)**:\n\n1. **Automated traceability**: Link regulatory requirements → test cases → execution results → GitLab commits  \n2. **Audit-ready documentation**: Complete test execution history with timestamps and pipeline references  \n3. **Risk management**: Real-time quality dashboards for risk assessment  \n4. **Regulatory reporting**: Generate compliance reports directly from QMetry test data\n\n**For aerospace certification (DO-178C, DO-254)**:\n\n1. **Automated traceability matrix**: QMetry links requirements → test cases → execution results → GitLab commits  \n2. **Immutable audit trail**: Every test execution is timestamped with pipeline ID, commit SHA, and executor  \n3. **Certification package generation**: QMetry generates compliant documentation pulling data from GitLab pipelines  \n4. **Real-time compliance dashboards**: Auditors can view test coverage and execution history in real-time\n\n## Complete configuration reference\n\nHere's a comprehensive reference of all available component inputs:\n\n| Input Parameter | Required | Default | Description |\n| ----- | ----- | ----- | ----- |\n| `stage` | No | `test` | GitLab CI/CD stage for the upload job |\n| `runner_tag` | No | `\"\"` | Specific runner tag to use (empty = any available runner) |\n| `project` | Yes | - | QMetry project name or key |\n| `file_name` | Yes | - | Path to test results file (relative to project root) |\n| `testing_type` | Yes | - | Test result format: `JUNIT`, `TESTNG`, `NUNIT`, etc. |\n| `skip_warning` | No | `\"1\"` | Skip warnings during import (`\"1\"` = skip, `\"0\"` = show) |\n| `is_matching_required` | No | `\"false\"` | Match existing test cases by name (`\"true\"` or `\"false\"`) |\n| `testsuite_name` | No | `\"\"` | Name for the test suite in QMetry |\n| `testsuite_id` | No | `\"\"` | Existing test suite ID to append results to |\n| `testsuite_folder_path` | No | `\"\"` | Folder path for organizing test suites (e.g., `/Regression/Sprint-23`) |\n| `automation_hierarchy` | No | `\"\"` | Hierarchy level for test organization (`\"1\"`, `\"2\"`, `\"3\"`, etc.) |\n| `testcase_fields` | No | `\"\"` | Custom fields for test cases (comma-separated: `field1=value1,field2=value2`) |\n| `testsuite_fields` | No | `\"\"` | Custom fields for test suites (comma-separated: `field1=value1,field2=value2`) |\n| `instance_url` | Yes | - | QMetry instance URL (store in CI/CD variable) |\n| `api_key` | Yes | - | QMetry API key (store in CI/CD variable, masked) |\n\n## Best practices for production use\n\nAs you scale your integration, follow these best practices:\n\n### Security\n\n* ✅ **Always use CI/CD variables** for sensitive data (API keys, URLs)  \n* ✅ **Mask and protect** API key variables  \n* ✅ **Rotate API keys** periodically (quarterly recommended)  \n* ✅ **Restrict API key permissions** to minimum required (write to test results only)  \n* ✅ **Use protected branches** for production test uploads\n\n### Performance\n\n* ✅ **Keep test result files reasonable size** (\\\u003C 10 MB recommended)  \n* ✅ **Split large test suites** into multiple jobs/files  \n* ✅ **Use parallel test execution** to reduce pipeline duration  \n* ✅ **Cache dependencies** to speed up test execution\n\n### Organization\n\n* ✅ **Use consistent naming conventions** for test suites and folder paths  \n* ✅ **Leverage custom fields** for filtering and reporting  \n* ✅ **Create folder hierarchies** that mirror your test strategy  \n* ✅ **Document your integration** in project README files\n\n### Troubleshooting\n\n* ✅ **Review job logs** for API communication details  \n* ✅ **Verify test result file format** matches `testing_type` parameter  \n* ✅ **Check QMetry project exists** and API key has access  \n* ✅ **Ensure test result files** are available as pipeline artifacts\n\n## Summary and next steps\n\nCongratulations! You've successfully integrated GitLab CI/CD with QMetry Test Management Enterprise. Your setup now provides:\n\n* **Automated test result uploads** – No more manual exports and imports \n\n* **Real-time visibility** – QA teams see results immediately after pipeline execution \n\n* **Complete traceability** – Link GitLab commits, pipelines, and test executions \n\n* **Enhanced compliance** – Maintain audit trails for regulated industries \n\n* **Scalable quality processes** – Support growing test suites without added overhead\n\n### What happens now\n\nEvery time your GitLab pipeline runs:\n\n1. Tests execute and generate result files.  \n2. The QMetry component automatically uploads results to your instance.  \n3. QA teams, stakeholders, and auditors see results in QMetry dashboards.  \n4. AI-powered insights analyze execution patterns and identify improvements.  \n5. Compliance reports generate automatically with full traceability.\n\n### Expand your integration\n\nNow that you have the basic integration working, consider these advanced scenarios:\n\n* **Bi-directional integration**: Use QMetry's API to trigger GitLab pipelines from test management workflows.\n\n* **Multi-project deployments**: Scale the component across your organization's GitLab projects.\n\n* **Custom reporting**: Build dashboards combining GitLab pipeline metrics with QMetry test analytics.\n\n* **Scheduled test execution**: Use GitLab scheduled pipelines to run regression suites nightly.\n\n## Learn more and get help\n\n### Documentation and resources\n\n* **Component documentation**: [GitLab CI/CD Catalog](https://gitlab.com/explore/catalog)  \n* **QMetry documentation**: [QMetry Support Portal](https://qmetrysupport.atlassian.net/wiki/spaces/QPro/overview)  \n* **SmartBear resources**: [SmartBear Academy](https://smartbear.com/resources/)  \n* **GitLab CI/CD documentation**: [GitLab CI/CD Documentation](https://docs.gitlab.com/ee/ci/)\n\n### Support\n\n**For component technical questions**:\n\n* Visit the [component repository](https://gitlab.com/sb9945614/qtm-gitlab-component).  \n* Open an issue on the project.  \n* Check existing issues for common questions.\n\n**For QMetry product questions**:\n\n* Contact SmartBear support at support@smartbear.com.  \n* Visit the [QMetry Community Forum](https://community.smartbear.com/).",{"featured":30,"template":15,"slug":765},"streamline-test-management-with-the-smartbear-qmetry-gitlab-component",{"content":767,"config":777},{"title":768,"description":769,"authors":770,"heroImage":772,"date":762,"body":773,"category":11,"tags":774},"GitLab Duo CLI: Agentic AI for the development lifecycle, now in the terminal","Developers who work outside the IDE and GitLab UI can access GitLab Duo Agent Platform in the terminal with built-in security controls and headless mode support.",[771],"John Coghlan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1775561395/bhe1as7ttjvzltxwgo5m.png","Debugging a broken pipeline at the end of a sprint, or wiring AI into a CI/CD workflow that runs without anyone watching, is exactly where today's AI assistants fall short given their focus on coding – which is only a portion of the software lifecycle. They're built for interactive coding sessions, not automation across different stages of software development. GitLab Duo CLI, now in public beta, is built for both.\n\nGitLab Duo CLI brings agentic AI powered by [Duo Agent Platform](https://about.gitlab.com/gitlab-duo-agent-platform/) to the terminal with full support for automated workflows, alongside an interactive chat mode when you need a human in the loop. This article highlights what Duo CLI does, how its two operating modes work, and the security model behind it.\n\n## How to install GitLab Duo CLI\n\nIf you already have GLab (the GitLab CLI) installed, enter:\n\n```\nglab duo cli\n```\n\nThen follow the prompts.\n\nIf you don't have GLab yet, you can [install it here](https://gitlab.com/gitlab-org/cli/#installation) or [use GitLab Duo CLI as a standalone tool](https://docs.gitlab.com/user/gitlab_duo_cli/#without-the-gitlab-cli).\n\n## Why the terminal, and why now\n\nThe first wave of AI assistants for software development lived in the IDE, and focused solely on coding. That made sense when the job was autocomplete. But as AI agents start *doing things* across every stage of the software lifecycle, e.g. running tests, triggering pipelines, monitoring vulnerability scans, and more, the IDE may no longer be the only abstraction needed to get the job done.\n\nThe best developer tools are ones that work for both humans and machines. CLIs have had decades of design iteration toward that goal. They're composable. You can pipe output, chain commands, and drop them into scripts. They're debuggable: when something goes wrong, you run the same command yourself and see exactly what the agent saw. And they're transparent. No background processes, no initialization dance, no protocol to decode when things break.\n\nTerminal interfaces are better for automation, scripting, and environment portability. IDE interfaces are better for interactive, context-rich development. GitLab Duo CLI is designed for the former, while Duo Agentic Chat in the IDE and UI covers the latter.\n\n## What GitLab Duo CLI can do\n\nWith GitLab Duo CLI, developers can build, modify, refactor, and modernize code — similar to other AI-powered coding assistants built for the terminal. But that’s not where they stop. Any agent and flow defined within GitLab Duo Agent Platform is accessible via Duo CLI, whether it is to automate CI/CD configuration and optimize pipelines, or to perform multi-step development tasks autonomously across the entire software development lifecycle.\n\nGitLab Duo CLI runs in two modes:\n\n* **Interactive mode**, an editor-agnostic terminal chat experience with human-in-the-loop approval before any action is taken. Use it to understand codebase structure, create code, fix errors, or troubleshoot broken pipelines.  \n* **Headless mode**, non-interactive, designed for runners, scripts, and automated workflows. Drop it into CI/CD and let it work without handholding.\n\n## AI with guardrails\n\nAgentic AI that can take actions creates real security exposure. GitLab Duo CLI addresses this at the platform level, not as an afterthought:\n\n* **Human-in-the-loop by default** in interactive mode, so no action is taken without approval.  \n* **Prompt injection detection** is built into the GitLab Duo Agent Platform, not bolted on.  \n* **Composite identity** limits what the agent can access and makes every AI-driven action auditable.\n\nGitLab Duo CLI also supports [custom instruction files](https://docs.gitlab.com/user/duo_agent_platform/customize/), e.g. `chat-rules.md`, `AGENTS.md`, and `SKILL.md`, that define which tasks, resources, context, knowledge, and actions your agents are permitted to take. **This is the principle of least privilege applied to AI: Your agent does exactly what you've authorized, and nothing more.**\n\nWatch GitLab Duo CLI in action:\n\u003Ciframe src=\"https://player.vimeo.com/video/1179964611?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo CLI Beta Demo V1\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Use GitLab Duo CLI today\n\nYou can experience the benefits of GitLab Duo CLI by [starting a free trial of GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo-agent-platform/). \n\nIf you are already using GitLab in the free tier, you can sign up for GitLab Duo Agent Platform by [following a few simple steps](https://docs.gitlab.com/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom). \n\nAnd if you are an existing subscriber to GitLab Premium or Ultimate, you can take advantage of GitLab Duo CLI by simply [turning on Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/turn_on_off/) and start using the GitLab Credits [that are included](https://docs.gitlab.com/subscriptions/gitlab_credits/#included-credits) with your subscription.",[775,11,776],"AI/ML","features",{"featured":30,"template":15,"slug":778},"gitlab-duo-cli",{"promotions":780},[781,795,806],{"id":782,"categories":783,"header":785,"text":786,"button":787,"image":792},"ai-modernization",[784],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":788,"config":789},"Get your AI maturity score",{"href":790,"dataGaName":791,"dataGaLocation":244},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":793},{"src":794},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":796,"categories":797,"header":798,"text":786,"button":799,"image":803},"devops-modernization",[11,569],"Are you just managing tools or shipping innovation?",{"text":800,"config":801},"Get your DevOps maturity score",{"href":802,"dataGaName":791,"dataGaLocation":244},"/assessments/devops-modernization-assessment/",{"config":804},{"src":805},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":807,"categories":808,"header":810,"text":786,"button":811,"image":815},"security-modernization",[809],"security","Are you trading speed for security?",{"text":812,"config":813},"Get your security maturity score",{"href":814,"dataGaName":791,"dataGaLocation":244},"/assessments/security-modernization-assessment/",{"config":816},{"src":817},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":819,"blurb":820,"button":821,"secondaryButton":826},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":822,"config":823},"Get your free trial",{"href":824,"dataGaName":51,"dataGaLocation":825},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":506,"config":827},{"href":55,"dataGaName":56,"dataGaLocation":825},1777310003251]