docs/content/actions/learn-github-actions/migrating-from-jenkins-to-github-actions.md

title, intro, redirect_from, versions, type, topics

title	intro	redirect_from	versions	type	topics
Migrating from Jenkins to GitHub Actions	{% data variables.product.prodname_actions %} and Jenkins share multiple similarities, which makes migration to {% data variables.product.prodname_actions %} relatively straightforward.	/actions/migrating-to-github-actions/migrating-from-jenkins-to-github-actions	free-pro-team enterprise-server * >=2.22	tutorial	Jenkins Migration CI CD

{% data reusables.actions.enterprise-beta %} {% data reusables.actions.enterprise-github-hosted-runners %}

Introduction

Jenkins and {% data variables.product.prodname_actions %} both allow you to create workflows that automatically build, test, publish, release, and deploy code. Jenkins and {% data variables.product.prodname_actions %} share some similarities in workflow configuration:

• Jenkins creates workflows using Declarative Pipelines, which are similar to {% data variables.product.prodname_actions %} workflow files.
• Jenkins uses stages to run a collection of steps, while {% data variables.product.prodname_actions %} uses jobs to group one or more steps or individual commands.
• Jenkins and {% data variables.product.prodname_actions %} support container-based builds. For more information, see "Creating a Docker container action."
• Steps or tasks can be reused and shared with the community.

For more information, see "Core concepts for {% data variables.product.prodname_actions %}."

Key differences

• Jenkins has two types of syntax for creating pipelines: Declarative Pipeline and Scripted Pipeline. {% data variables.product.prodname_actions %} uses YAML to create workflows and configuration files. For more information, see "Workflow syntax for GitHub Actions."
• Jenkins deployments are typically self-hosted, with users maintaining the servers in their own data centers. {% data variables.product.prodname_actions %} offers a hybrid cloud approach by hosting its own runners that you can use to run jobs, while also supporting self-hosted runners. For more information, see About self-hosted runners.

Comparing capabilities

Distributing your builds

Jenkins lets you send builds to a single build agent, or you can distribute them across multiple agents. You can also classify these agents according to various attributes, such as operating system types.

Similarly, {% data variables.product.prodname_actions %} can send jobs to {% data variables.product.prodname_dotcom %}-hosted or self-hosted runners, and you can use labels to classify runners according to various attributes. The following table compares how the distributed build concept is implemented for both Jenkins and {% data variables.product.prodname_actions %}.

Jenkins	{% data variables.product.prodname_actions %}
agents	runners self-hosted runners

Using sections to organize pipelines

Jenkins splits its Declarative Pipelines into multiple sections. Similarly, {% data variables.product.prodname_actions %} organizes its workflows into separate sections. The table below compares Jenkins sections with the {% data variables.product.prodname_actions %} workflow.

Jenkins Directives	{% data variables.product.prodname_actions %}
agent	jobs.<job_id>.runs-on jobs.<job_id>.container
post
stages	jobs
steps	jobs.<job_id>.steps

Using directives

Jenkins uses directives to manage Declarative Pipelines. These directives define the characteristics of your workflow and how it will execute. The table below demonstrates how these directives map to concepts within {% data variables.product.prodname_actions %}.

Jenkins Directives	{% data variables.product.prodname_actions %}
environment	jobs.<job_id>.env jobs.<job_id>.steps[*].env
options	jobs.<job_id>.strategy jobs.<job_id>.strategy.fail-fast jobs.<job_id>.timeout-minutes
parameters	inputs outputs
triggers	on on.<event_name>.types on.<push|pull_request>.<branches|tags> on.<push|pull_request>.paths
triggers { upstreamprojects() }	jobs.<job_id>.needs
Jenkins cron syntax	on.schedule
stage	jobs.<job_id> jobs.<job_id>.name
tools	Specifications for {% data variables.product.prodname_dotcom %}-hosted runners
input	inputs
when	jobs.<job_id>.if

Using sequential stages

Parallel job processing

Jenkins can run the stages and steps in parallel, while {% data variables.product.prodname_actions %} currently only runs jobs in parallel.

Jenkins Parallel	{% data variables.product.prodname_actions %}
parallel	jobs.<job_id>.strategy.max-parallel

Build matrix

Both {% data variables.product.prodname_actions %} and Jenkins let you use a build matrix to define various system combinations.

Jenkins	{% data variables.product.prodname_actions %}
axis	strategy/matrix context
stages	steps-context
excludes

Using steps to execute tasks

Jenkins groups steps together in stages. Each of these steps can be a script, function, or command, among others. Similarly, {% data variables.product.prodname_actions %} uses jobs to execute specific groups of steps.

Jenkins steps	{% data variables.product.prodname_actions %}
script	jobs.<job_id>.steps

Examples of common tasks

Scheduling a pipeline to run with cron

Jenkins Pipeline	{% data variables.product.prodname_actions %} Workflow
pipeline { agent any triggers { cron('H/15 * * * 1-5') } }	on: schedule: - cron: '*/15 * * * 1-5'

Configuring environment variables in a pipeline

Jenkins Pipeline	{% data variables.product.prodname_actions %} Workflow
pipeline { agent any environment { MAVEN_PATH = '/usr/local/maven' } }	jobs: maven-build: env: MAVEN_PATH: '/usr/local/maven'

Building from upstream projects

Jenkins Pipeline	{% data variables.product.prodname_actions %} Workflow
pipeline { triggers { upstream( upstreamProjects: 'job1,job2', threshold: hudson.model.Result.SUCCESS ) } }	jobs: job1: job2: needs: job1 job3: needs: [job1, job2]

Building with multiple operating systems

Jenkins Pipeline	{% data variables.product.prodname_actions %} Workflow
pipeline { agent none stages { stage('Run Tests') { matrix { axes { axis { name: 'PLATFORM' values: 'macos', 'linux' } } agent { label "${PLATFORM}" } stages { stage('test') { tools { nodejs "node-12" } steps { dir("scripts/myapp") { sh(script: "npm install -g bats") sh(script: "bats tests") } } } } } } } }	{% raw %} name: demo-workflow on: push: jobs: test: runs-on: ${{ matrix.os }} strategy: fail-fast: false matrix: os: [macos-latest, ubuntu-latest] steps: - uses: actions/checkout@v1 - uses: actions/setup-node@v1 with: node-version: 12 - run: npm install -g bats - run: bats tests working-directory: scripts/myapp {% endraw %}