Enable TI for Ruby

Using Test Intelligence (TI) in your Harness CI pipelines doesn't require you to change your build and test processes.

Enable TI for Ruby

You can enable TI for Ruby in three steps:

Add the Run Tests step.
Trigger test selection.
(Optional) Add test splitting.

Add the Run Tests step

Add the Run Tests step to the Build stage in a CI pipeline.

You must select Run only selected tests (runOnlySelectedTests: true) to enable Test Intelligence. For information about each setting, go to Run Tests step settings.

- step:
    type: RunTests
    name: Run Ruby Tests
    identifier: Run_Ruby_Tests
    spec:
      language: Ruby
      buildTool: Rspec
      runOnlySelectedTests: true ## Must be 'true' to enable TI.

For additional YAML examples, go to Pipeline examples

Trigger test selection

After adding the Run Tests step, trigger test selection. You need to run your pipeline twice to trigger test selection.

Trigger test selection with a webhook trigger (Recommended)

Trigger test selection with a manual build

Why do I have to run the pipeline twice?

The first time you run a pipeline after adding the Run Test step, Harness creates a baseline for test selection in future builds. Test selection isn't applied to this run because Harness has no baseline against which to compare changes and select tests. You'll start seeing test selection and time savings on the second run after adding the Run Tests step.

Add test splitting

Once you start saving time with test selection, you can further optimize test times by enabling parallelism (test splitting) for TI.

You can also configure TI to ignore tests or files.

Pipeline examples

Video demo

YAML examples

Harness Cloud
Self-managed

This example shows a pipeline that:

Uses Harness Cloud build infrastructure.
Uses a Run step to install dependencies. This is not always required; it depends on your build infrastructure and needs.
Runs tests on Ruby with RSpec and Test Intelligence.
Uses parallelism (parallelism, enableTestSplitting) to further improve test times.

- stage:
    strategy:
      parallelism: 2
    name: test
    identifier: test
    type: CI
    spec:
      cloneCodebase: true
      platform:
        os: Linux
        arch: Amd64
      runtime:
        type: Cloud
        spec: {}
      execution:
        steps:
          - step:
              type: Run
              name: Dependencies
              identifier: dependencies
              spec:
                shell: Sh
                command: |-
                  apt-get update -y
                  apt -y install libarchive-tools
          - step:
              type: RunTests
              name: Run Tests
              identifier: run_tests
              spec:
                language: Ruby
                buildTool: Rspec
                testGlobs: "**/test/unit/**/*_test.rb" ## Optional
                runOnlySelectedTests: true ## Must be 'true' to use TI.
                enableTestSplitting: true ## Optional. Apply parallelism to further improve test times.

This example shows a pipeline that uses a Kubernetes cluster build infrastructure and runs tests on Ruby with RSpec and Test Intelligence.

pipeline:
  projectIdentifier: default
  orgIdentifier: default
  identifier: testintelligencedemo
  name: Test Intelligence Demo
  properties:
    ci:
      codebase:
        connectorRef: YOUR_CODEBASE_CONNECTOR_ID
        repoName: YOUR_CODE_REPO_NAME
        build: <+input>
  tags: {}
  stages:
    - stage:
        name: Ruby tests
        identifier: rubytests
        type: CI
        spec:
          cloneCodebase: true
          execution:
            steps:
              - step:
                  type: Run Ruby Tests
                  name: Run_Ruby_Tests
                  identifier: Run_Ruby_Tests
                  spec:
                    connectorRef: account.harnessImage ## Specify if required by your build infrastructure.
                    image: ruby:latest ## Specify if required by your build infrastructure.
                    language: Ruby
                    buildTool: Rspec
                    runOnlySelectedTests: true ## Must be 'true' to use TI.
          infrastructure:
            type: KubernetesDirect
            spec:
              connectorRef: YOUR_KUBERNETES_CLUSTER_CONNECTOR_ID
              namespace: YOUR_KUBERNETES_NAMESPACE
              automountServiceAccountToken: true
              nodeSelector: {}
              os: Linux

Run Tests step settings

The following information explains how to configure most settings for the Run Tests step. You might not need all settings for all scenarios; some settings are optional, and some settings are only available for specific languages, build tools, or build infrastructures.

Container Registry and Image

The build environment must have the necessary binaries for the Run Tests step to execute your test commands. Depending on the stage's build infrastructure, Run Tests steps can use binaries that exist in the build environment, or use Container Registry and Image to pull an image, such as a public or private Docker image, that contains the required binaries. You can also install tools at runtime in Pre-Command, provided the build machine or image can execute the necessary commands, such as curl commands to download files.

When are Container Registry and Image required?

What are the expected values for Container Registry and Image?

Language

Select Ruby.

Build Tool

Select RSpec.

Build Arguments

This setting is optional for Ruby. You can provide additional runtime arguments for tests, such as --format RspecJunitFormatter --out tmp/junit.xml. You don't need to repeat the build tool; this is declared in Build Tool.

Test Report Paths

This setting is optional for Ruby. You can use this setting if you want your test reports to be stored somewhere other than the default location or have a different name than the default report name.

You can specify one or more paths to files that store test results in JUnit XML format. Glob is supported.

reports:
  type: JUnit
  spec:
    paths:
      - tmp/junit.xml

You can add multiple paths. If you specify multiple paths, make sure the files contain unique tests to avoid duplicates.

Test splitting (parallelism)

Used to enable test splitting (parallelism) for TI.

Pre-Command, Post-Command, and Shell

Pre-Command: Enter commands for setting up the environment before running the tests.
Post-Command: You can enter commands used for cleaning up the environment after running the tests.
Shell: If you supplied a script in Pre-command or Post-command, select the corresponding shell script type.

Run Only Selected Tests

This option must be selected (true) to enable Test Intelligence.

If this option is not selected (false), TI is disabled and all tests run on every build.

Test Globs

You can override the default test globs pattern. For example, the default for RSpec is **/spec/**/*_spec.rb, and you could override it with any other pattern, such as spec/features/**/*_spec.rb, which would look for a /spec directory at the root level, rather than anywhere in the workspace.

Environment Variables

You can inject environment variables into the step container and use them in the step's commands. You must input a Name and Value for each variable.

You can reference environment variables in the Build Arguments, Pre-Command, or Post-Command scripts by name, such as $var_name.

Variable values can be fixed values, runtime inputs, or expressions. For example, if the value type is expression, you can input a value that references the value of some other setting in the stage or pipeline.

Using an expression for an environment variable's value.

Stage variables

Stage variables are inherently available to steps as environment variables.

Additional container settings

Settings specific to containers are not applicable in a stages that use VM or Harness Cloud build infrastructure.

Image Pull Policy

If you specified a Container Registry and Image, you can specify an image pull policy:

Always: The kubelet queries the container image registry to resolve the name to an image digest every time the kubelet launches a container. If the kubelet encounters an exact digest cached locally, it uses its cached image; otherwise, the kubelet downloads (pulls) the image with the resolved digest, and uses that image to launch the container.
If Not Present: The image is pulled only if it isn't already present locally.
Never: The image is not pulled.

Run as User

If you specified a Container Registry and Image, you can specify the user ID to use for running processes in containerized steps.

For a Kubernetes cluster build infrastructure, the step uses this user ID to run all processes in the pod. For more information, go to Set the security context for a pod.

Privileged

For container-based build infrastructures, you can enable this option to run the container with escalated privileges. This is equivalent to running a container with the Docker --privileged flag.

Set Container Resources

These settings specify the maximum resources used by the container at runtime. These setting are only available for container-based build infrastructures, such as a Kubernetes cluster build infrastructure.

Limit Memory: The maximum memory that the container can use. You can express memory as a plain integer or as a fixed-point number using the suffixes G or M. You can also use the power-of-two equivalents Gi and Mi. The default is 500Mi.
Limit CPU: The maximum number of cores that the container can use. CPU limits are measured in CPU units. Fractional requests are allowed. For example, you can specify one hundred millicpu as 0.1 or 100m. The default is 400m. For more information go to Resource units in Kubernetes.

Timeout

The timeout limit for the step. Once the timeout is reached, the step fails and pipeline execution proceeds according to any Step Failure Strategy settings or Step Skip Condition settings.

Troubleshoot Test Intelligence

Go to the CI Knowledge Base for questions and issues related to Test Intelligence, including: