Skip to content

Running Tests in CI/CD

Overview

Martini provides an official Docker image that automatically runs every test in a Martini project and produces a standard test report, with no manual steps required. Add it as a step or job in any CI/CD pipeline — GitHub Actions, Bitbucket Pipelines, Jenkins, GitLab CI, or similar — to run your project's tests whenever code changes and fail the build if any test fails. This page assumes you're already familiar with what a test and a test run are in Martini; it focuses on running that same test suite unattended, in a pipeline, rather than interactively in Martini Designer.

The image is published on Docker Hub as lontiplatform/martini-designer-ci-tests, with the following tags available:

  • latest — the most recent release.
  • A specific version number (e.g. 1.8.0) — matches a specific Martini Designer release, for reproducible pipelines.

What You Will Learn

  • What you need before running the image in a pipeline
  • How to run the image against your project with a minimal command
  • How the container discovers, starts, and runs your project's tests
  • Where the JUnit test report is written and what it contains
  • How to restrict a run to a subset of tests
  • Which environment variables configure the container's behavior
  • How to wire the image into GitHub Actions, GitLab CI, or Bitbucket Pipelines
  • How to troubleshoot common CI/CD run failures

Prerequisites

  • A machine or runner that can run Docker containers.
  • A valid Martini license.
  • Your Martini project available as a folder that can be mounted into the container — for example, your pipeline's own checked-out source code.

Running the CI Tests Image

Run the image with docker run, mounting your project folder into the container's workspace path and passing your license as an environment variable:

1
2
3
4
docker run --rm \
  -e MR_LICENSE="<your-martini-license>" \
  -v /path/to/your/project:/home/martini/martini-designer-workspace \
  lontiplatform/martini-designer-ci-tests
  • Replace /path/to/your/project with the path to your Martini project on the host or runner.
  • The container exits with a non-zero status if any test fails or errors, and with a zero status if every test passes — this is what lets your pipeline mark the step as failed or passed.

Expected result: the container logs show Martini Designer and Martini Runtime starting, followed by each discovered test executing, and the process exits with a status code your pipeline can check.

Note: The container runs as the non-root node user built into the base image (uid 1000). If you bind-mount your own project onto /home/martini/martini-designer-workspace, make sure the mounted folder is writable by this user or its group — otherwise the container may fail to read or write files in your project.

How the CI Tests Image Works

The container automates the same test run you'd otherwise trigger manually from Test Explorer:

  1. It starts Martini Designer in the background and automatically opens your mounted project as its workspace — no manual project selection, login, or other UI interaction is needed.
  2. It performs a full project and runtime setup on startup, so each CI run always starts from a clean, up-to-date state rather than reusing stale state from a previous run.
  3. Once Martini Designer is up and running, it:
  4. Waits for the Martini Runtime and every package in your project to fully finish starting.
  5. Automatically discovers every test defined in your project — no need to list or register them anywhere.
  6. Runs all of them, start to finish, without any user input.
  7. When the run finishes — or if something prevented it from running, such as the runtime failing to start in time — a test report is written out.
  8. The container inspects that report and exits accordingly, so the pass/fail result flows straight into your pipeline's own reporting.

Reading the JUnit Test Report

Results are written as a JUnit XML report, the same format produced by most mainstream test runners, so it works out of the box with CI systems' built-in test result views, annotations, and history or trend graphs.

  • By default, the report is written to a test-results/junit.xml file inside your project folder, so it ends up on the host or runner alongside your checked-out code and can be picked up by your pipeline's test-reporting step or published as a build artifact.
  • The report includes, per test: pass, fail, error, or skipped status, duration, and failure messages or stack traces where relevant.
  • If the run couldn't start at all — for example, the Martini Runtime didn't finish starting within the allowed time — the report still gets produced, containing a single entry describing what went wrong. This ensures a pipeline step consuming the report never hangs or is left without any result to show.

Filtering Which Tests Run

By default, every test in the project runs. Restrict a run to a subset of tests by providing a file-path pattern (glob) with the MARTINI_CI_TEST_PATTERN environment variable, matched against each test's location relative to the project root. Use this when splitting tests across multiple pipeline stages or jobs, or when you only want to run tests relevant to a particular part of the project.

CI Tests Image Configuration Reference

Pass configuration to docker run through environment variables with -e.

Environment variable Required/Default Description
MR_LICENSE Required Your Martini license, needed to start Martini Runtime.
MARTINI_CI_WORKSPACE_PATH Defaults to /home/martini/martini-designer-workspace Path inside the container where your project should be mounted. Change this when your CI system mounts or checks out code to a different path, such as when you use this image as a custom pipeline container.
MARTINI_CI_TEST_PATTERN Defaults to all tests Glob pattern that limits execution to tests whose paths, relative to the project root, match the pattern.
MARTINI_CI_RUNTIME_STARTUP_TIMEOUT Defaults to 60000 (60 seconds, in milliseconds) How long to wait for Martini Runtime and the project to finish starting before failing the run. Increase this for larger projects that need more time to start.

The container can be used the same way in any platform that supports running Docker images, including GitHub Actions, GitLab CI, and Bitbucket Pipelines. The examples below run the image against the pipeline's own checked-out source and publish the resulting JUnit report using each platform's native test-reporting support.

GitHub Actions

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
permissions:
  contents: read
  actions: read
  checks: write

jobs:
  martini-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Make workspace writable by the test container
        run: sudo chown -R 1000:1000 "$GITHUB_WORKSPACE"
      - name: Run Martini tests
        run: |
          docker run --rm \
            -e MR_LICENSE="${{ secrets.MR_LICENSE }}" \
            -v "${{ github.workspace }}:/home/martini/martini-designer-workspace" \
            lontiplatform/martini-designer-ci-tests
      - uses: dorny/test-reporter@v1
        if: always()
        with:
          name: Martini Test Report
          path: test-results/junit.xml
          reporter: java-junit

The contents, actions, and checks permissions allow dorny/test-reporter to publish the report as a GitHub check. For pull requests from forks, use the action's artifact and workflow_run pattern instead, because fork workflows receive a read-only GITHUB_TOKEN.

GitLab CI

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
martini-tests:
  stage: test
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker run --rm
      -e MR_LICENSE="$MR_LICENSE"
      -v "$CI_PROJECT_DIR:/home/martini/martini-designer-workspace"
      lontiplatform/martini-designer-ci-tests
  artifacts:
    when: always
    reports:
      junit: test-results/junit.xml

Bitbucket Pipelines

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
pipelines:
  default:
    - step:
        name: Run Martini tests
        script:
          - docker run --rm
            -e MR_LICENSE="$MR_LICENSE"
            -v "$BITBUCKET_CLONE_DIR:/home/martini/martini-designer-workspace"
            lontiplatform/martini-designer-ci-tests
        after-script:
          - pipe: atlassian/junit-report-converter:0.2.1
        services:
          - docker

In each example, store your Martini license as a pipeline-level secret or protected variable (MR_LICENSE) rather than hardcoding it, and mount the pipeline's own checkout path into the container's workspace path, as described in Running the CI Tests Image.

Troubleshooting CI Tests Image Issues

Run fails immediately with a license error

  • Detection: Container logs report a license failure.
  • Cause: MR_LICENSE is missing, invalid, or expired.
  • Fix: Double-check the MR_LICENSE value and confirm that it is a valid, active Martini license.

Run times out waiting for startup

  • Detection: The container exits with a startup timeout message, and the JUnit report contains a single entry describing the failure.
  • Cause: The project has many packages and needs more time to fully initialize.
  • Fix: Increase MARTINI_CI_RUNTIME_STARTUP_TIMEOUT.

Before wiring the image into your pipeline, try it locally against a local clone of your project to confirm your license and project are set up correctly.

Helpful Resources