Git Actions

GitHub Actions

GitHub Actions is a feature of GitHub that allows you to automate, customize, and execute your software development workflows right in your repository. With GitHub Actions, you can build, test, and deploy your code directly from GitHub, with world-class support for CI/CD.

In addition, GitHub Actions allows you to automate other aspects of your development workflow such as assigning code reviews, managing branches, and triaging issues.

How it works

GitHub Actions workflows are event-driven: you define what should happen and when it should be triggered. The workflow file lives inside your repository at .github/workflows/, making it version-controlled alongside your code.

flowchart LR
    event(["Event\ne.g. push to main"]):::gray
    workflow(["Workflow\n.github/workflows/*.yml"]):::blue
    jobs(["Jobs\nrun in parallel or sequence"]):::blue
    steps(["Steps\nshell commands or actions"]):::teal
    runner(["Runner\nGitHub-hosted VM\nor self-hosted"]):::green

    event --> workflow --> jobs --> steps
    steps -.->|"executes on"| runner

    classDef gray  fill:#F1EFE8,stroke:#888780,color:#2C2C2A
    classDef blue  fill:#E6F1FB,stroke:#185FA5,color:#042C53
    classDef teal  fill:#E1F5EE,stroke:#0F6E56,color:#04342C
    classDef green fill:#EAF3DE,stroke:#3B6D11,color:#173404

Core concepts

Example — CI pipeline for a Spring Boot microservice

The workflow below triggers on every push to main and on pull requests. It checks out the code, sets up Java, runs the tests, and builds the Docker image.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source
        uses: actions/checkout@v4

      - name: Set up Java 21
        uses: actions/setup-java@v4
        with:
          java-version: '21'
          distribution: 'temurin'
          cache: maven

      - name: Run tests
        run: mvn test --no-transfer-progress

      - name: Build artifact
        run: mvn package -DskipTests --no-transfer-progress

      - name: Build Docker image
        run: docker build -t ${{ secrets.DOCKERHUB_USERNAME }}/account-service:${{ github.sha }} .

      - name: Push to Docker Hub
        run: |
          echo "${{ secrets.DOCKERHUB_TOKEN }}" | docker login -u "${{ secrets.DOCKERHUB_USERNAME }}" --password-stdin
          docker push ${{ secrets.DOCKERHUB_USERNAME }}/account-service:${{ github.sha }}

Example — CD: deploy to Kubernetes after a successful CI run

This second workflow triggers only after the CI workflow passes on main, then updates the Kubernetes deployment using kubectl.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

name: CD

on:
  workflow_run:
    workflows: [CI]
    types: [completed]
    branches: [main]

jobs:
  deploy:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: ubuntu-latest

    steps:
      - name: Configure kubectl
        uses: azure/setup-kubectl@v3

      - name: Write kubeconfig
        run: |
          mkdir -p $HOME/.kube
          echo "${{ secrets.KUBECONFIG }}" | base64 -d > $HOME/.kube/config

      - name: Rolling update
        run: |
          kubectl set image deployment/account-service \
            account-service=${{ secrets.DOCKERHUB_USERNAME }}/account-service:${{ github.sha }}
          kubectl rollout status deployment/account-service --timeout=120s

GitHub Actions vs Jenkins

Both tools implement the same CI/CD concepts, but with different trade-offs: