CI: add GitHub Actions pipeline with Maven build and tests

[alicewersen-rgb]

This PR adds a GitHub Actions CI pipeline for the backend project.

Changes included:

• Adds .github/workflows/ci.yml with a workflow to build the project and run tests
• Configures Java 25 for the CI environment
• Uses Maven to build and verify the project
• Ensures that the build fails if tests fail

This setup allows automatic verification of code on every push or pull request to main/develop branches.

Summary by CodeRabbit

Release Notes

• Chores
  • Added continuous integration pipeline that automatically builds and verifies code on push and pull request events to main and develop branches.

[coderabbitai]

📝 Walkthrough

Walkthrough

A new GitHub Actions CI workflow has been added to automatically build and test the project. The workflow triggers on push and pull requests targeting main and develop branches, executing Maven clean verify on Ubuntu with Java 25.

Changes

Cohort / File(s)	Summary
GitHub Actions CI Workflow .github/workflows/ci.yml	Added new CI pipeline configuration that triggers on push/PR events, sets up Java 25 with Temurin distribution, and runs Maven build and test verification.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

Possibly related issues

• #102: Directly related—both changes introduce/modify the same CI workflow file (.github/workflows/ci.yml) for setting up Java/Maven build and test automation.

Poem

🐰 A workflow so swift, in YAML it springs,
Java and Maven, the testing it brings,
On every commit, the pipeline will race,
Building and testing with automated grace! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: adding a GitHub Actions CI pipeline with Maven build and test capabilities.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/ci-pipeline

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (3)

.github/workflows/ci.yml (3)

18-21: Add Maven dependency caching for faster builds.

Configure Maven dependency caching to improve build performance by avoiding redundant downloads on subsequent runs.

⚡ Proposed enhancement to add Maven caching

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

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci.yml around lines 18 - 21, Add Maven dependency caching
to the CI workflow by inserting an actions/cache@v4 step before the build that
caches the Maven local repository (e.g. path: ~/.m2/repository) and uses a key
that includes runner OS and a checksum of pom.xml (or build files) with
restore-keys for partial hits; keep the existing actions/setup-java@v4 and
java-version: '25' step but ensure the cache step runs prior to mvn
package/verify so dependencies are restored from the cache when available.

---

23-24: Consider adding test results reporting.

Publishing test results would improve observability and make it easier to diagnose failures without downloading artifacts or checking raw logs.

📊 Proposed enhancement to publish test results

Add after the Maven build step:

      - name: Publish test results
        uses: dorny/test-reporter@v1
        if: always()
        with:
          name: Maven Tests
          path: '**/target/surefire-reports/TEST-*.xml'
          reporter: java-junit

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci.yml around lines 23 - 24, Add a new CI step to publish
Maven test results after the "Build and test with Maven" step by using the
dorny/test-reporter action: create a step named like "Publish test results" that
runs unconditionally (if: always()) and points to the Surefire XML reports (path
'**/target/surefire-reports/TEST-*.xml') with reporter 'java-junit' so test
failures and results are uploaded and visible in the workflow UI.

---

23-24: Testcontainers Docker dependency is present and properly configured.

The project uses Testcontainers with PostgreSQL (pom.xml dependencies include spring-boot-testcontainers and testcontainers-postgresql). TestcontainersConfiguration.java creates a PostgreSQLContainer bean that requires Docker runtime. The CI workflow runs on ubuntu-latest, which has Docker pre-installed and running by default, so the current setup will work for Testcontainers tests without additional configuration.

If you want to make Docker availability more explicit or use the existing compose.yaml for integration tests, you could add a Docker service step, but it's not required for the current ubuntu-latest environment.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci.yml around lines 23 - 24, The CI currently runs the
"Build and test with Maven" step with mvn clean verify on ubuntu-latest which
already includes Docker, so no change is required for Testcontainers to run; if
you prefer to make Docker availability explicit or reuse compose.yaml for
integration tests, add an explicit Docker service or a step that starts
Docker/loads compose before the "Build and test with Maven" job so the
PostgreSQLContainer in TestcontainersConfiguration.java can reliably access the
Docker runtime during tests.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/ci.yml:
- Around line 23-24: The CI step named "Build and test with Maven" is calling
the system Maven binary ("mvn clean verify") which ignores the project's pinned
Maven wrapper; update that step to invoke the project's Maven wrapper (use
"./mvnw clean verify" on Linux runners) so the build uses the version specified
by .mvn/wrapper/maven-wrapper.properties and remains consistent with local
builds.

---

Nitpick comments:
In @.github/workflows/ci.yml:
- Around line 18-21: Add Maven dependency caching to the CI workflow by
inserting an actions/cache@v4 step before the build that caches the Maven local
repository (e.g. path: ~/.m2/repository) and uses a key that includes runner OS
and a checksum of pom.xml (or build files) with restore-keys for partial hits;
keep the existing actions/setup-java@v4 and java-version: '25' step but ensure
the cache step runs prior to mvn package/verify so dependencies are restored
from the cache when available.
- Around line 23-24: Add a new CI step to publish Maven test results after the
"Build and test with Maven" step by using the dorny/test-reporter action: create
a step named like "Publish test results" that runs unconditionally (if:
always()) and points to the Surefire XML reports (path
'**/target/surefire-reports/TEST-*.xml') with reporter 'java-junit' so test
failures and results are uploaded and visible in the workflow UI.
- Around line 23-24: The CI currently runs the "Build and test with Maven" step
with mvn clean verify on ubuntu-latest which already includes Docker, so no
change is required for Testcontainers to run; if you prefer to make Docker
availability explicit or reuse compose.yaml for integration tests, add an
explicit Docker service or a step that starts Docker/loads compose before the
"Build and test with Maven" job so the PostgreSQLContainer in
TestcontainersConfiguration.java can reliably access the Docker runtime during
tests.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b5b06250-9d83-43cb-9846-ddaae86b1719

📥 Commits

Reviewing files that changed from the base of the PR and between be2c8af and 5a60855.

📒 Files selected for processing (1)

• .github/workflows/ci.yml

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Use Maven wrapper for consistent builds.

The project has a Maven wrapper configured (.mvn/wrapper/maven-wrapper.properties) that pins Maven 3.9.14, but the CI uses bare mvn instead of ./mvnw. This bypasses the pinned version and may cause different build behavior between local development (where developers use ./mvnw) and CI (which uses whatever Maven version ubuntu-latest provides).

🔧 Proposed fix to use Maven wrapper

       - name: Build and test with Maven
-        run: mvn clean verify
+        run: ./mvnw clean verify

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci.yml around lines 23 - 24, The CI step named "Build and
test with Maven" is calling the system Maven binary ("mvn clean verify") which
ignores the project's pinned Maven wrapper; update that step to invoke the
project's Maven wrapper (use "./mvnw clean verify" on Linux runners) so the
build uses the version specified by .mvn/wrapper/maven-wrapper.properties and
remains consistent with local builds.