Git Github Action

Building CI with GitHub Actions

I used to redeploy manually via scripts triggered by cron or Airflow. That approach required a machine running 24/7 and only synced on a schedule—not ideal. While researching Jenkins, I stumbled upon 생활코딩’s GitHub Actions video and realized GitHub already provides a lightweight CI/CD solution.

Here’s how I set up a CI pipeline that builds a Spring Boot app, packages it into a Docker image, and pushes to Docker Hub.


What Is GitHub Actions?

GitHub Actions is GitHub’s native CI/CD service. You create YAML workflows under .github/workflows/. GitHub offers starter templates tailored to your repo—check the Actions tab or browse the docs.


Workflow Overview

I wanted the pipeline to trigger on pushes/PRs to master, build the project, and push an updated image. Later, Kubernetes pulls from Docker Hub.

The full workflow is in this gist:

Key sections:

name: gradle and docker

on:
  push:
    branches: [master]
  pull_request:
    branches: [master]

on defines when the workflow runs.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 11
  • runs-on: provision an Ubuntu runner.
  • actions/checkout@v2: pull the repo.
  • actions/setup-java@v1: install JDK 11.

Docker Hub login & build steps:

Sensitive values (like DOCKER_PASSWORD) come from GitHub Secrets: Repository Settings → Secrets → Actions.

The final step builds the Docker image and pushes it.


Testing

After committing the workflow, GitHub runs it automatically. Future pushes/PRs trigger new runs.

A green check means success. Click through for logs and errors. If something fails, GitHub emails you (if notifications are enabled).

Workflows live under .github/workflows/; edit them directly in the repo to iterate.

I stopped at CI because I plan to handle CD with Argo CD (I love its dashboard). Stay tuned for a separate post.


Lessons Learned

  • Environment variables are scoped per step. Define and use them within the same run block, or persist them if needed. I initially tried editing .bashrc inside a step—it doesn’t survive subsequent steps.
  • When in doubt, cram debugging commands into a single step to keep state.

GitHub Actions turned out to be much simpler than maintaining my own Jenkins or cron-based scripts, and it ties directly to repo activity—exactly what I needed for CI.***