Skip to main content

Continuous Integration (CI) FAQs

This article addresses some frequently asked questions about Harness Continuous Integration (CI).

In this topic:

General​

How can a step call service dependency?​

A step can call a service dependency on localhost or 127.0.0.1along with the port on which the service dependency is running. See Configure service dependency.

What is the maximum timeout for a CIE step or stage?​

We have a maximum time limit of 24 hours for pod uptime. Hence, the CI stage can run for a maximum of 24 hours, and post that the pod dies.

The default Timeout for a CIE step is 10h.

What are the default values for memory and CPU for CIE steps?​

MemoryCPU
500Mi400m

How to replicate a list of Drone plugin settings in CIE?​

For lists, merge them separated by a comma.

For example:

DroneCIE

| 

 Settings:    tags:      - latest      - '1.0.1'      - '1.0'

| 

Settings:    tags: latest,1.0.1,1.0

|

Permissions required for GitHub personal access token in NextGen and GitX.​

GitHub permission for personal access token (PAT) in NextGen:

Permissions required to run CIE builds in an OpenShift cluster.​

You need the following permissions on Secret, Pod, and Event to run the CIE builds in an OpenShift cluster:

create

get

list

watch

update

delete

List of minimum permissions required for service account role for a Kubernetes connector.​

You need the following permissions for a service account role for a Kubernetes connector:

Pods and secrets

create

get

list

watch

update

delete

Events

list

watch

How can you share the codebase configuration between stages in the CIE pipeline?​

You can use the Save and restore cache steps to share data between stages. Each CIE stage runs in a different pod. The workspace allows you to share data between different steps in the same stage.

Does CIE support running Docker-in-Docker images?​

Yes! See Run Docker-in-Docker in a CI stage.

How can you execute Docker commands in a CI pipeline that runs on a Kubernetes cluster that lacks a Docker runtime?​

DinD (Docker-in-Docker) can be run as a service, with the shared path set to /var/run. Following that, the steps can be executed as Docker commands. This works regardless of the Kubernetes container runtime.

The DinD service does not connect to the Kubernetes node daemon. It launches a new Docker daemon on the pod, and other containers use that Docker daemon to run their commands.