Jenkins to GitHub Actions path - Commands & Configuration

Introduction

Moving from Jenkins to GitHub Actions helps teams use built-in GitHub automation without managing separate servers. It solves the problem of maintaining Jenkins infrastructure by using cloud-hosted workflows integrated with your code repository.

When you want to automate testing and deployment directly from your GitHub repository without extra servers

When your Jenkins server is hard to maintain or update and you want a simpler cloud solution

When you want to use GitHub's marketplace of ready-made actions to speed up your pipeline setup

When you want to trigger workflows on GitHub events like pull requests or pushes automatically

When you want to reduce costs by using GitHub's free tier for CI/CD instead of running Jenkins agents

Config File - ci.yml

ci.yml

name: CI Pipeline

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'temurin'

      - name: Build with Maven
        run: mvn clean install

      - name: Run tests
        run: mvn test

This GitHub Actions workflow named CI Pipeline runs on pushes and pull requests to the main branch.

The build job runs on a fresh Ubuntu machine.

Steps include checking out the code, setting up Java 11, building with Maven, and running tests.

Commands

Clone your GitHub repository locally to add the GitHub Actions workflow file.

Terminal

git clone https://github.com/example-user/example-repo.git

Expected Output

Cloning into 'example-repo'...

remote: Enumerating objects: 10, done.

remote: Counting objects: 100% (10/10), done.

remote: Compressing objects: 100% (7/7), done.

remote: Total 10 (delta 1), reused 10 (delta 1), pack-reused 0

Receiving objects: 100% (10/10), done.

Resolving deltas: 100% (1/1), done.

Create the workflows directory and copy the GitHub Actions workflow file into the repository folder.

Terminal

mkdir -p example-repo/.github/workflows && cp ci.yml example-repo/.github/workflows/ci.yml

Expected Output

No output (command runs silently)

Add the workflow file to git, commit with a message, and push to the main branch to trigger the workflow.

Terminal

cd example-repo && git add .github/workflows/ci.yml && git commit -m "Add GitHub Actions CI workflow" && git push origin main

Expected Output

[main abc1234] Add GitHub Actions CI workflow

 1 file changed, 20 insertions(+)

 create mode 100644 .github/workflows/ci.yml

Enumerating objects: 5, done.

Counting objects: 100% (5/5), done.

Delta compression using up to 4 threads

Compressing objects: 100% (3/3), done.

Writing objects: 100% (3/3), 500 bytes | 500.00 KiB/s, done.

Total 3 (delta 0), reused 0 (delta 0)

To https://github.com/example-user/example-repo.git

   def5678..abc1234  main -> main

Check the status of recent GitHub Actions workflow runs using GitHub CLI.

Terminal

gh run list --repo example-user/example-repo

Expected Output

Workflow runs for example-user/example-repo



ID     NAME       STATUS    CONCLUSION  EVENT       BRANCH  AGE

123456 CI Pipeline completed success    push       main    2m ago

→

--repo - Specify the repository to check workflow runs

Key Concept

If you remember nothing else from this path, remember: GitHub Actions workflows live inside your repo and run automatically on GitHub events, replacing Jenkins server jobs.

Common Mistakes

Not placing the workflow file in the correct .github/workflows directory

GitHub Actions only detects workflows inside the .github/workflows folder, so the workflow won't run if misplaced.

Always put your YAML workflow files inside the .github/workflows directory at the root of your repository.

Pushing workflow changes to a branch other than the one configured in the workflow triggers

The workflow triggers only run on specified branches like main, so pushing to other branches won't start the workflow.

Ensure your workflow triggers include the branches you push to, or push to the configured branches like main.

Forgetting to commit and push the workflow file after creating it locally

GitHub Actions workflows run only after the workflow file is pushed to the repository.

After adding or editing workflow files, commit and push them to the remote repository to activate the workflows.

Summary

Create a GitHub Actions workflow YAML file inside .github/workflows to define your CI/CD pipeline.

Push the workflow file to your repository to trigger automated runs on events like push or pull request.

Use GitHub CLI or the GitHub web interface to monitor workflow run status and results.

Practice

1. What is the main difference between Jenkins and GitHub Actions in terms of where the automation configuration is stored?

easy

A. Both Jenkins and GitHub Actions store workflows only on external servers.

B. GitHub Actions stores workflow files inside the repository, Jenkins uses an external server.

C. Jenkins stores workflows inside the repository, GitHub Actions uses an external server.

D. Both Jenkins and GitHub Actions store workflows only inside the repository.

Solution

1. Step 1: Understand Jenkins workflow storage

   Jenkins typically stores job configurations on its own server, separate from the code repository.

2. Step 2: Understand GitHub Actions workflow storage

   GitHub Actions stores workflow YAML files directly inside the code repository under the .github/workflows directory.

3. Final Answer:

   GitHub Actions stores workflow files inside the repository, Jenkins uses an external server. -> Option B

4. Quick Check:

   Workflow location = repository for GitHub Actions [OK]

Hint: Remember: GitHub Actions config lives with your code [OK]

Common Mistakes:

• Thinking Jenkins stores configs in the repo
• Assuming GitHub Actions uses external servers only
• Confusing storage locations for both tools

2. Which of the following is the correct syntax to trigger a GitHub Actions workflow on a push to the main branch?

easy

A. on: push: branches: [main]

B. trigger: push main

C. event: push branch main

D. when: push to main

Solution

1. Step 1: Recall GitHub Actions trigger syntax

   The correct YAML syntax uses 'on:' followed by the event type and branches list.

2. Step 2: Match syntax to options

   on: push: branches: [main] matches the correct YAML format: 'on: push: branches: [main]'. Others are invalid YAML or incorrect keywords.

3. Final Answer:

   on: push: branches: [main] -> Option A

4. Quick Check:

   Trigger syntax = 'on:' keyword [OK]

Hint: GitHub Actions triggers start with 'on:' in YAML [OK]

Common Mistakes:

• Using 'trigger' instead of 'on' keyword
• Incorrect YAML indentation or keywords
• Confusing event names and branch filters

3. Given this GitHub Actions workflow snippet, what will happen when a pull request is opened?

on:
  pull_request:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Run tests
        run: echo "Tests running..."

medium

A. The workflow runs only when a pull request targets the main branch.

B. The workflow runs on any pull request regardless of target branch.

C. The workflow runs only on push events, not pull requests.

D. The workflow will fail due to syntax errors.

Solution

1. Step 1: Analyze the trigger section

   The workflow triggers on pull_request events targeting the 'main' branch only.

2. Step 2: Understand job execution

   When a pull request is opened against 'main', the job runs the steps: checkout and echo test message.

3. Final Answer:

   The workflow runs only when a pull request targets the main branch. -> Option A

4. Quick Check:

   Trigger filters = pull_request on main branch [OK]

Hint: Check 'on:' and branch filters to predict workflow triggers [OK]

Common Mistakes:

• Assuming it runs on all pull requests
• Confusing push and pull_request triggers
• Thinking syntax is invalid when it is correct

4. You migrated a Jenkins pipeline to GitHub Actions but the workflow does not run on push events. Which is the most likely cause?

medium

A. The workflow file is named with a .json extension instead of .yml.

B. The Jenkinsfile syntax was copied directly into the GitHub Actions YAML.

C. The repository is private and GitHub Actions only works on public repos.

D. The workflow YAML file is not placed under the .github/workflows directory.

Solution

1. Step 1: Check workflow file location

   GitHub Actions requires workflow files to be inside the .github/workflows folder to detect and run them.

2. Step 2: Evaluate other options

   Copying Jenkinsfile syntax won't run but does not prevent detection; GitHub Actions works on private repos; file extension must be .yml or .yaml, but location is primary cause.

3. Final Answer:

   The workflow YAML file is not placed under the .github/workflows directory. -> Option D

4. Quick Check:

   Workflow location = .github/workflows folder [OK]

Hint: Put workflow files in .github/workflows folder [OK]

Common Mistakes:

• Ignoring file location importance
• Assuming Jenkinsfile syntax works in GitHub Actions
• Thinking GitHub Actions only runs on public repos

5. You want to convert a Jenkins pipeline that runs tests on multiple operating systems into a GitHub Actions workflow. Which approach correctly replicates this behavior?

hard

A. Create separate workflows for each OS and trigger them manually.

B. Use a single job with a shell script that switches OS environments inside the runner.

C. Use a matrix strategy in GitHub Actions to run jobs on ubuntu-latest, windows-latest, and macos-latest runners.

D. GitHub Actions does not support multiple OS testing; use Jenkins instead.

Solution

1. Step 1: Understand Jenkins multi-OS testing

   Jenkins pipelines can run parallel jobs on different OS agents to test across environments.

2. Step 2: Use GitHub Actions matrix strategy

   GitHub Actions supports a matrix strategy to run the same job on multiple OS runners like ubuntu-latest, windows-latest, and macos-latest automatically.

3. Final Answer:

   Use a matrix strategy in GitHub Actions to run jobs on ubuntu-latest, windows-latest, and macos-latest runners. -> Option C

4. Quick Check:

   Matrix strategy = multi-OS testing [OK]

Hint: Use matrix to test multiple OS in one workflow [OK]

Common Mistakes:

• Trying to switch OS inside one runner
• Creating many manual workflows instead of matrix
• Believing GitHub Actions lacks multi-OS support