UDT-Gitlab CI Integration

GitLab is a one-stop DevOps platform covering code development, version control, CI/CD, and project management. It supports the entire workflow from code development to deployment and operations without integrating additional third-party tools.

WeTest UDT is a one-stop test management platform focusing on test case management, automated test execution, test result analysis, and test resource scheduling.

Their integration seamlessly connects the full-process loop of code development → test execution → quality feedback → issue fixing, deeply integrating testing into the DevOps workflow and truly realizing quality shift-left and test automation. With UDT’s multi-device parallel testing and automated execution capabilities, it can significantly shorten test cycles, improve test coverage, control product quality from the source, and ensure high-quality and smooth application launches.

WeTest UDT is now integrated with GitLab CI. This document details the working principles, value, and operation guide of the integration between UDT and GitLab.

If you wish to experience all the features of the UDT platform’s integration with GitLab pipelines, please contact us. WeTest testing experts will provide one-on-one guidance to help you complete the setup for your first integration.

Value of UDT-GitLab CI Integration

The core value of UDT + GitLab CI integration is embedding device testing capabilities into the R&D pipeline, which significantly improves testing efficiency:
1.End-to-end automation, eliminating inefficiencies and errors caused by manual intervention
Core Value: When code submissions or merge requests trigger the GitLab CI pipeline, it automatically invokes designated devices on the UDT platform to execute tests. There is no need to manually log in to the UDT platform for device selection, network configuration, or test initiation.

2.Parallel testing across multiple devices and platforms, improving efficiency and reducing costs
Core Value: GitLab CI can batch schedule multiple devices on the UDT platform for parallel test execution, replacing manual validation on each device one by one and greatly improving test coverage.

3.Closed-loop test result feedback, enabling more timely issue reporting
Core Value: Test results from the UDT platform (including failure screenshots, logs, and performance data) can be automatically sent back to GitLab CI and stored as pipeline artifacts. Developers can directly view issues on the GitLab pipeline page without switching to the UDT platform, making issue troubleshooting more efficient.

Integration Principles

GitLab identifies the configured YAML file under the project instance and distributes test tasks to the cloud device pool of the UDT platform. This YAML file defines all rules of the GitLab CI/CD pipeline, including specifying pipeline trigger rules, dividing pipeline stages, configuring execution environments and dependencies, passing UDT authentication credentials, writing core execution scripts, and processing and archiving test results, thus serving as the centralized control for the entire integration solution.

Prerequisites

1.A GitLab account, associated project, and relevant instances
2.A UDT platform account and corresponding test project

Basic Configuration

1.Upload the package to be tested in advance in Repository > Applications on the UDT platform.
2.Go to Project > Settings > CI/CD in GitLab, find Variables > Project Variables, and add the required prerequisite variable values.

• Select Variable as the type and All as the environment.
• Configure the visibility according to your requirements.
• Modify the values of keys such as IOS_UDID and UDT_DEVICE_ID based on the test devices to be used. Note that there is no need to configure the device serial number for Android devices, but the corresponding iOS device serial number (i.e., IOS_UDID) must be configured for iOS device testing.
• Configure the values of other variables according to your actual UDT account and UDT project information.

Configuration Within a GitLab Project

Description of Core Modules

The following is a Demo project:



Description of All Files in This Project：

udt-gitlab-ci-demo/
├── .gitlab-ci.yml                # Main pipeline configuration file
├── generate_test_yml.py          # Dynamically generates test sub-pipeline configurations
├── run_tests.py                  # Unified test entry script (includes Appium connection management)
├── save_udt_artifacts.py         # Downloads and saves test artifacts from UDT
├── conftest.py                   # Pytest configuration and shared fixtures
├── requirements.txt              # Python test dependencies
├── tests/                        # Test case directory
│   ├── __init__.py
│   ├── test_android.py
│   ├── test_ios.py
│   └── test_web.py
├── test-reports/                 # Auto-generated test report and screenshot directory
│   ├── android/
│   │   ├── report.xml
│   │   └── screenshots/
│   ├── ios/
│   │   ├── report.xml
│   │   └── screenshots/
│   └── web/
│       ├── report.xml
│       └── screenshots/
└── simple/
    └── .gitlab-ci.yml            # Minimalist CI configuration example

• .gitlab-ci.yml
  Main pipeline configuration file that defines CI pipeline stages and task dependencies.

• generate_test_yml.py
  Purpose: Dynamically generates GitLab CI child pipeline configuration files for test execution based on the configuration.
  Description: Implements the distribution and parallel execution of test tasks through the child pipeline mechanism.

• run_tests.py
  Purpose: Unified entry point for test execution, which manages Appium connections and schedules test cases.
  Local Screenshots: If you need to capture screenshots during testing, please import and call the take_screenshot method at the test entry point.

• save_udt_artifacts.py
  Purpose: Downloads the artifacts generated during test execution (screenshots, videos, logs, and test reports) from the UDT platform and uploads them to the GitLab CI artifact repository.

YAML File Writing Guide

Create a file named .gitlab-ci.yml in the root directory of the GitLab project. Below is sample code for a pipeline file configured for multi-device parallel testing.

stages:
  - Initialize test configuration
  - Start testing


variables:
  PYTHON_VERSION: "3.9"

  UDT_PROJECT_UNIQUE_IDENTIFIER: $UDT_PROJECT_UNIQUE_IDENTIFIER
  UDT_USER_ID: $UDT_USER_ID
  UDT_USER_KEY: $UDT_USER_KEY
  UDT_PROJECT_TOKEN: $UDT_PROJECT_TOKEN
  UDT_APP_ID: $UDT_APP_ID
  APP_PACKAGE: $APP_PACKAGE
  APP_ACTIVITY: $APP_ACTIVITY
  IOS_UDID: $IOS_UDID
  PLATFORM: $PLATFORM
  UDT_JOB_NAME: $UDT_JOB_NAME


image: python:$PYTHON_VERSION


before_script:
  - pip install virtualenv -i https://mirrors.aliyun.com/pypi/simple/
  - virtualenv venv
  - source venv/bin/activate

  - pip config set global.index-url https://mirrors.aliyun.com/pypi/simple
  - pip config set global.trusted-host mirrors.aliyun.com
  - pip install pyyaml

# Generate dynamic test configuration
generate_test_yml:
  stage: Initialize test configuration
  script:
    - |
      python generate_test_yml.py
      echo "Generated configuration:"
      cat test-pipeline.yml
  artifacts:
    paths:
      - test-pipeline.yml
    expire_in: 30 mins

# Trigger testing
Start testing:
  stage: Start testing
  trigger:
    include:
      - artifact: test-pipeline.yml
        job: generate_test_yml
    strategy: depend

• Environment Variable Configuration
  Required variables to be preconfigured in the CI/CD ➔ Variables page of the GitLab project.

• Test Case Management
  Test cases are stored in the tests/ directory and written separately by platform.All tests are invoked uniformly via run_tests.py.

• Artifact Path Customization
  GitLab artifact storage structure: Can be adjusted in generate_test_yml.py.
  UDT artifact download logic: Can be modified in save_udt_artifacts.py.

• Dependency Managemen
  trequirements.txt contains only the Python dependencies required for test cases.
  Dependencies for other modules in the CI pipeline are directly written in .gitlab-ci.yml and can be modified as needed.

• Pipeline Triggering
  There are two trigger methods:
  Automatic trigger: Triggered by default when a commit is pushed.
  Manual trigger: Access via Build → Pipelines → New Pipeline → New Pipeline.
  Note: For any modifications, it is recommended to start a new pipeline rather than re-run an existing one.

• Variable Management
  Variables and their values for the pipeline run can be passed in when triggering the pipeline manually.
  Pipeline variable priority: Variables explicitly defined in YAML file > Variables passed in during manual trigger > Variables configured in settings.
  
  

Pipeline Task Creation

Go to Project → Build → Pipelines, select an existing pipeline, and click Run.

Pipeline Progress Monitoring

Go to Project > Build > Jobs, locate the test-running pipeline, and click it to view the detailed execution progress.
Once the process is completed, the corresponding UDT platform task link will be displayed here. Click the link to navigate to the UDT platform and check the task’s execution status and report.



The pipeline displays the concurrent testing status of multiple devices separately. Select any device and click to navigate to its detailed test logs.

View Custom Test Artifacts

Click Browse on the right side of the test logs to view the artifacts generated during testing.

You can also find the artifacts in Project > Build > Artifacts.

Should you have additional integration requirements or encounter any issues during the integration process, please contact us. We will arrange for our testing experts to provide one-on-one support to understand your requirements and assist with your testing.