Skip to main content

Migrate from GitHub Actions to Harness CI

Harness CI and GitHub Actions both allow you to create workflows that automatically build, test, publish, release, and deploy code.

Harness does not require scripting, and configurations are passed to pipelines securely and pragmatically. In contrast, GitHub Actions provides third-party actions that you use with semi-plug-and-play functionality.

What makes Harness CI unique?

Harness CI provides proprietary technologies, like Cache Intelligence and Test Intelligence, that make Harness CI four times faster than other leading CI tools.

  • Harness Test Intelligence (TI) is a proprietary technology that accelerates test cycles by running only the tests necessary to confirm the quality of the code changes that triggered a build. Visualizations show which code changes caused which tests to be selected, and TI can help you identify gaps in your test plan. TI also detects negative trends and provides actionable insights to improve quality. With TI, it's possible to reduce build cycle times by up to 90% without compromising application quality.
  • Harness Cache Intelligence is a proprietary technology that reduces pipeline execution time by automatically caching well-known directories for languages like Java and Node.js.

Harness CI is part of The Harness Platform, which is a self-service CI/CD platform that enables end-to-end software delivery. The Harness Platform includes features, functionality, and additional modules to help you build, test, deploy, and verify software. For example:

  • Role-Based Access Control (RBAC) helps you control user and group access to Harness resources according to users' roles. Using RBAC increases security and improves efficiency.
  • Harness Policy as Code is a centralized policy management and rules service that leverages the Open Policy Agent (OPA) to meet compliance requirements across software delivery and enforce governance policies.
  • The Harness Enterprise Ready Self-Managed Edition is an end-to-end solution for continuous, self-managed delivery. You can install and update Harness Self-Managed Enterprise Edition using online or offline (air-gapped) methods.

GitHub Actions plugins

Harness CI offers built-in support for GitHub Actions. You can use the GitHub Action step in pipelines that use Harness Cloud build infrastructure. For other build infrastructures, you can use the GitHub Actions Drone plugin in a Plugin step.

Other advantages

Harness CI offers the following additional advantages over GitHub Actions:

  • Harness offers a variety of build infrastructure options, including Apple silicon and Linux arm64 options.
  • Harness supports both Terraform and CloudFormation infrastructure provisioning with simpler structures and configurations than their corresponding GitHub Actions.
  • GitHub Actions does not provide a native Accelerate metrics dashboard, whereas Harness offers both a dedicated dashboard and the ability to configure alerts.

Comparison: Workflow architecture

Both Harness CI and GitHub Actions use workflows to organize builds. In Harness CI, these workflows are called pipelines. In both products, workflows are divided into major segments, which are called stages in Harness CI and jobs in GitHub Actions. Each stage or job includes one or more steps or individual commands.

In GitHub Actions, if a job has a lot of steps, those steps might be organized into groups, which are called stages. Similarly, in Harness CI, you can use step groups to group steps within a stage.

The following truncated examples provide a simple comparison of stage and step structure in GitLab CI and Harness CI.

  stages:
- stage:
name: stage1
...
spec:
...
platform:
os: Linux
arch: Amd64
...
execution:
steps:
- step:
type: Run
name: compile code
identifier: compile_code
spec:
connectorRef: myDockerHubConnector
image: python:3.10.6-alpine
shell: Sh
command: python -m compileall ./

For more information about Harness terminology, features, and pipeline components, go to the CI key concepts.

Both Harness CI and GitHub Actions workflows are written in YAML. Whereas GitHub Actions workflow configurations are always stored in the .github/workflows directory in your code repo, Harness provides you a choice of inline pipeline storage or importing pipelines from Git. Harness also provides both visual and code-based pipeline editors.

  • The Harness YAML editor includes schema validation and auto-complete recommendations to simplify and expedite pipeline configuration.
  • The Harness visual editor provides a guided experience that enables anyone to easily build, debug, and run pipelines.
  • You can switch back and forth between editors.
Complete workflow comparison

Here are YAML examples of complete workflows in GitHub Actions and Harness CI.

pipeline:
name: gha-test
identifier: ghatest
projectIdentifier: gha_test
orgIdentifier: default
tags: {}
properties:
ci:
codebase:
connectorRef: account.myscm
repoName: test
build: <+input>
stages:
- stage:
name: stage1
identifier: stage1
description: ""
type: CI
spec:
cloneCodebase: true
platform:
os: Linux
arch: Amd64
runtime:
type: Cloud
spec: {}
execution:
steps:
- step:
type: Background
name: postgres-dependency
identifier: postgresdependency
spec:
connectorRef: myDockerHubConnector
image: postgres:10.8
shell: Sh
envVariables:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: <+secrets.getValue("DbPasswordSecret")>
POSTGRES_DB: postgres
- step:
type: Run
name: Run_1
identifier: Run_1
spec:
connectorRef: myDockerHubConnector
image: openjdk:17.0-jdk
shell: Bash
command: echo "this runs on openjdk"
- stage:
name: stage2
identifier: stage2
description: ""
type: CI
spec:
cloneCodebase: true
execution:
steps:
- step:
type: Run
name: Run_2
identifier: Run_2
spec:
connectorRef: myDockerHubConnector
image: node:13.0.0
shell: Bash
command: |-
echo "pipeline var:" <+pipeline.variables.pipelinevar1>
echo "project level var:" <+variable.proj_var>
echo "secret example :" <+secrets.getValue("DbPasswordSecret")>
platform:
os: Linux
arch: Amd64
runtime:
type: Cloud
spec: {}
- stage:
name: matrix stage
identifier: matrix_stage
description: ""
type: CI
spec:
cloneCodebase: true
platform:
os: Linux
arch: Amd64
runtime:
type: Cloud
spec: {}
execution:
steps:
- step:
type: Run
name: Run_3
identifier: Run_3
spec:
shell: Bash
command: echo "Testing on <+matrix.testparam>"
strategy:
matrix:
testparam:
- node
- python
- ubuntu
maxConcurrency: 3
variables:
- name: pipelinevar1
type: String
description: ""
value: someval
Root and non-root users

Steps run as the root user, generally. For example, with Harness Cloud build infrastructure, steps run directly on the host and, therefore, run as the root user.

For services running on containers (which are steps where you specify a Container Registry and Image to use to execute the step's commands), you can use the Run as User setting to specify a user to use for that container.

With Kubernetes cluster build infrastructure, you can use the Run as User setting to specify a user to use for individual steps, or you can set a default user for all steps and then override the default user as needed for individual steps.

Comparison: Clone a codebase

GitHub Actions workflows are inherently associated with a code repo because the workflow YAML exists in the .github/workflows directory in the target code repo. The workflow can use actions/checkout in a step to clone the associated codebase into the workflow workspace.

name: Github_actions
on:
pull_request:
branches:
- main
jobs:
job_1:
name: job_1
...
steps:
- name: Checkout code
uses: actions/checkout@v2

Comparison: Access Docker

To log in to Docker Hub in a GitHub Actions workflow, you use docker/login-action in a step. You then use other docker actions in other steps to pull images, push images, and so on.

  name: login to docker hub
uses: docker/login-action@v2
with:
username: {{ secrets.DOCKERHUB_USERNAME }}
password: {{ secrets.DOCKERHUB_TOKEN }}

name: build and push docker image
uses: docker/build-push-action@v3
with:
context:
file: ./pythondockerfile
push: true
tags: user/pythonsample:latest

Comparison: Environment variables

In GitHub Actions, you can use predefined environment variables, define custom variables within a single workflow, or define custom variables at the organization, account, and environment levels. You can use predefined environment variables or define custom variables.

This range of variable definition is also possible in Harness CI. In addition to built-in variables, you can define variables within individual pipelines, stages, and steps as well as at the project, organization, and account levels.

This GitHub Actions example defines environment variables at the workflow and job levels.

env:
ENV_VAR: value1

jobs:
job_1:
runs-on: ubuntu-latest
env:
JOB_VAR: value2
steps:
- name: simple script
run: echo "$JOB_VAR $ENV_VAR"

Comparison: Matrix jobs

In both Harness CI and GitHub Actions, you can define matrix strategies for your jobs to iterate over a series of inputs. In both products, you define a matrix strategy and then call the strategy by it's tag or other identifier when you want to use it in a command or step.

In Harness, matrix looping strategies are one of several looping execution strategies. To learn about the looping strategies available in Harness, go to Use looping strategies

The following example describes a stage in a Harness CI pipeline that includes one step with matrix and parallelism strategies. The looping strategies are defined in strategy at the stage level. One matrix strategy, called testparam, is defined in matrix and parallelism is defined by maxConcurrency: 3. The script in the Run step calls the inputs from the matrix strategy by using the expression +matrix.testparam>.

  stages:
- stage:
name: Stage1
...
steps:
- step:
type: Run
name: step1
identifier: step1
spec:
shell: Bash
command: echo "Testing on <+matrix.testparam>"
strategy:
matrix:
testparam:
- node
- python
- ubuntu
maxConcurrency: 3

Comparison: Triggers

In GitHub Actions, triggers are defined in the workflow based on Git events against specified branches or conditions.

Harness CI supports webhook, artifact, manifest and schedule triggers. The two most commonly used triggers are webhook triggers based on Git events and scheduled triggers based on cron expressions. To learn more about creating triggers, go to:

This GitHub Actions trigger listens for specific words in the name of pull requests against the main branch.

on:
pull_request:
branches:
- main
jobs:
gobuild:
if: contains(github.event.pull_request.labels.*.name, 'go') || contains(github.event.pull_request.labels.*.name, 'gojava')

See also

Review the following information before proceeding with migration: