CI/CD for Java Projects: GitHub Actions from A to Z

Introduction: Why CI/CD is the Standard of Modern Java Development

In the world of Java development, the speed and quality of code delivery are critical. Every day, teams make hundreds of changes, and without automation, the integration process turns into chaos. CI/CD (Continuous Integration / Continuous Deployment) solves this problem: code is automatically built, tested, and deployed to servers.

The GitHub Actions tool is a built-in CI/CD solution right in the repository. It allows you to create pipelines (workflows) in YAML that react to push, pull request, or other events. In this article, we will break down the full cycle of setting up CI/CD for a Java project: from a basic build to cloud deployment.

You will learn how to speed up development, avoid errors, and automate routine tasks. Let's go!

1. GitHub Actions Basics: Workflow Structure

What is GitHub Actions?

GitHub Actions is a platform for automating workflows. A workflow is a set of steps that are executed when an event occurs (e.g., a push to the main branch). Each workflow consists of:

\n
• Event — a trigger (push, pull_request, schedule).
\n
• Jobs — tasks that run on virtual machines (runners).
\n
• Steps — specific actions (running a script, installing dependencies).
\n

For a Java project, a typical workflow includes: checking out code, setting up JDK, building with Maven/Gradle, running tests, and publishing artifacts.

Creating Your First Workflow for Java

Create a .github/workflows/ folder in the root of your repository and a ci.yml file. Here is a minimal example for a Maven project:

name: Java CI with Maven\n\non:\n  push:\n    branches: [ main ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n\n    steps:\n    - uses: actions/checkout@v4\n    - name: Set up JDK 17\n      uses: actions/setup-java@v4\n      with:\n        java-version: '17'\n        distribution: 'temurin'\n    - name: Build with Maven\n      run: mvn clean compile\n    - name: Run tests\n      run: mvn test

This workflow runs on push or pull request to main. It checks that the code compiles and tests pass. If a test fails, the workflow ends with an error, and you receive a notification.

2. Advanced Configuration: Caching, Matrices, and Artifacts

Dependency Caching

Maven and Gradle download dependencies from scratch every time — this is slow. GitHub Actions supports caching. Add a step with actions/cache:

- name: Cache Maven packages\n  uses: actions/cache@v4\n  with:\n    path: ~/.m2/repository\n    key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}\n    restore-keys: |\n      ${{ runner.os }}-maven-

The cache key is based on the hash of pom.xml. If the file hasn't changed, dependencies are restored from the cache, reducing build time by 2-3 times.

Matrix Build

Java projects are often tested on multiple JDK versions and operating systems. Use the matrix strategy:

jobs:\n  test:\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        java: [11, 17, 21]\n    steps:\n    - uses: actions/checkout@v4\n    - name: Set up JDK ${{ matrix.java }}\n      uses: actions/setup-java@v4\n      with:\n        java-version: ${{ matrix.java }}\n        distribution: 'temurin'\n    - name: Test with Maven\n      run: mvn test

GitHub will create 3 parallel jobs — for Java 11, 17, and 21. This guarantees code compatibility with different JDK versions.

Saving Artifacts

After the build, the JAR file can be saved as an artifact to download manually or use in the next job:

- name: Upload JAR artifact\n  uses: actions/upload-artifact@v4\n  with