← Back to all posts
Article

Jenkins vs GitHub Actions for a Beginner's First Pipeline

Author:

Run the same shell check through a GitHub workflow or Jenkinsfile, then choose by runner access, controller maintenance, environment, and credentials.

Blue and violet workflow arrows connected by rounded execution nodes

If your goal is to make a repository test run after a change, GitHub Actions can start with a workflow file and an available runner. Jenkins can run the same test, but someone must also provide a working Jenkins service, the Pipeline capability, a job, and an execution node.

That extra responsibility may be exactly what you want to learn. Choose by the operational work you want to take on, rather than by counting integrations.

This comparison covers one Linux shell check. Official documentation was checked October 13, 2026. The check was tested locally; the pipeline wrappers below are documented configurations, not evidence of a hosted GitHub run or a tested Jenkins installation.

Keep the test outside the orchestrator

Put the following in check.sh, beside message.txt containing ready:

#!/usr/bin/env bash
set -eu
actual=$(cat message.txt)
if [ "$actual" != 'ready' ]; then
  printf 'Expected ready, got <%s>\n' "$actual" >&2
  exit 1
fi
printf 'message check passed\n'

bash check.sh passes with ready and returns 1 with broken. Command substitution removes trailing newlines; this is a value check rather than a byte-format test. Keeping the acceptance condition in the repository lets either system execute the same logic.

Do not move a different test into each configuration and then compare their results. First establish that the same revision, command, and expected failure condition are involved.

The smallest useful wrappers have different prerequisites

A GitHub workflow at .github/workflows/message-check.yml can be:

name: Message check
on:
  push:
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - run: bash check.sh

This selects a GitHub-hosted Linux runner and checks out the repository before running the script. The Actions quickstart supplies the configuration model. The checkout project documents the current major and execution requirements. Existing self-hosted runners may need updates before supporting a newer action runtime.

A Declarative Jenkinsfile can express the same job:

pipeline {
    agent { label 'linux' }
    stages {
        stage('Check message') {
            steps {
                sh 'bash check.sh'
            }
        }
    }
}

For this form, configure a Pipeline from SCM job or a Multibranch Pipeline so Jenkins retrieves the repository and reads its Jenkinsfile. Declarative Pipeline performs its normal SCM checkout unless that behavior is disabled. The label linux is a label you assign to a suitable node; it does not provision Linux or install Bash.

If you instead paste a pipeline into an inline job with no SCM context, this example has no repository source to check out. Configure the source or add an appropriate checkout step. The Jenkins Pipeline documentation and syntax reference describe those distinctions.

Committing a Jenkinsfile alone also does not establish an automatic trigger. Configure the job’s SCM integration, webhook, or polling policy. In contrast, the GitHub example explicitly declares the push event inside the workflow.

Choose who maintains the execution environment

Responsibility GitHub-hosted runner example Jenkins example
Scheduling service GitHub provides the Actions service A Jenkins controller must be operated
Test execution Hosted Linux runner selected by label Suitable node selected by configured label
Repository access Checkout uses the workflow’s read access SCM access must be configured for the job
Environment changes Hosted image and action runtimes evolve Operator maintains node tools and compatibility
Service maintenance Repository owner manages workflow and policy Operator also manages controller, plugins, backups, and availability
First failure to investigate Event, checkout, runner, or test step Trigger, SCM, node availability, Pipeline setup, or test step

Jenkins distinguishes the controller’s coordination role from agents that execute work. The agents guide explains that separation. A beginner environment may combine roles, but that should not become an assumption about a production installation.

GitHub Actions also supports self-hosted runners. Choosing one moves host maintenance and isolation responsibility toward you; it removes much of the operational difference highlighted by this hosted-runner example. “Actions versus Jenkins” is incomplete without specifying the runner model.

Add credentials only when the task needs them

The shell check needs no deployment secret. A private repository still needs authorized checkout access, and Jenkins may need a configured SCM credential. Do not put a password or token in the script or Jenkinsfile to make checkout work.

For either system, consider what code the job is allowed to execute and which credentials it can reach. A branch proposed by an untrusted contributor has a different trust boundary from a script you wrote in a private practice repository. This comparison does not set up deployment permissions or prescribe a universal contributor policy.

Decide from the first lesson you want

Use GitHub-hosted Actions when your repository is on GitHub, execution is enabled for your account, and the immediate lesson is a tested revision producing a meaningful check. Inspect current runner access and billing conditions before assuming every job is included.

Use an existing Jenkins environment when you need to learn its jobs and agents, or when the team already operates it. Build a separate learning installation only if controller and node operation are part of your goal; the small check does not itself require that work.

In either case, change ready to broken, confirm the failed job belongs to that revision, then repair it. If you can explain the trigger, checkout, execution location, and failure line, you have a first pipeline worth extending.

References