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: