Conversation
Co-authored-by: Copilot <copilot@github.com>
There was a problem hiding this comment.
Pull request overview
This PR introduces CI/CD automation for the Java/Spring Boot backend, aiming to validate commit messages, run tests with coverage, automate version bumping on dev, and deploy on main after successful CI runs.
Changes:
- Add GitHub Actions workflows for CI (commit validation + tests), release PR automation on
dev, and CD deployments to ECR/Docker Hub onmain. - Add a JaCoCo coverage rule to the Maven build.
- Remove the test docker-compose file and Maven wrapper properties, and switch the Maven project version from
-SNAPSHOTto a release version.
Reviewed changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 10 comments.
Show a summary per file
| File | Description |
|---|---|
| pom.xml | Sets release version and adds JaCoCo coverage check configuration. |
| docker-compose-test.yaml | Removed test compose file previously used for a test DB container. |
| .mvn/wrapper/maven-wrapper.properties | Removed Maven wrapper properties. |
| .github/workflows/ci.yml | Defines CI entry workflow (commit validation + tests). |
| .github/workflows/cd.yml | Defines CD entry workflow triggered after CI on main. |
| .github/workflows/release.yml | Defines release automation entry workflow triggered after CI on dev. |
| .github/workflows/_validate-commits.yml | Implements Conventional Commits validation logic. |
| .github/workflows/_test.yml | Implements Maven test/verify run for CI. |
| .github/workflows/_bump-version.yml | Implements semantic version bumping based on commit history. |
| .github/workflows/_create-release-pr.yml | Creates a release branch + PR to main. |
| .github/workflows/_check-version.yml | Compares current pom.xml version to latest GitHub release tag. |
| .github/workflows/_deploy-ecr.yml | Builds and pushes a multi-arch image to Amazon ECR. |
| .github/workflows/_deploy-dockerhub.yml | Builds and pushes a multi-arch image to Docker Hub. |
Comments suppressed due to low confidence (1)
docker-compose-test.yaml:1
- This file is still referenced by
Makefile(targetup-test-databaseuses-f docker-compose-test.yaml). Deleting it will break that developer workflow; either keep this compose file or update/remove the Makefile target accordingly.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - name: Commit and push | ||
| run: | | ||
| git config user.name "github-actions[bot]" | ||
| git config user.email "github-actions[bot]@users.noreply.github.com" | ||
| git add pom.xml | ||
| git commit -m "chore: bump version to ${{ steps.version.outputs.new }}" | ||
| git push |
There was a problem hiding this comment.
git push here relies on the currently checked-out branch and upstream configuration. In GitHub Actions this can be brittle (especially if checkout ends up in a detached state or on an unexpected ref); consider pushing explicitly to the intended branch (e.g., origin HEAD:<target-branch>) derived from an input to avoid accidental pushes to the wrong branch.
| - name: Check out code | ||
| uses: actions/checkout@v4 | ||
|
|
There was a problem hiding this comment.
The deploy builds from whatever actions/checkout defaults to in this reusable workflow. To ensure you publish the exact artifact that passed CI, accept a sha (or ref) input from the caller and check out that commit explicitly here before docker buildx build.
| - name: Check out code | ||
| uses: actions/checkout@v4 | ||
|
|
There was a problem hiding this comment.
Same as ECR: this workflow should build from a known commit SHA rather than the default ref to avoid deploying code that differs from what CI validated. Add a sha/ref input and set actions/checkout ref: accordingly.
| <execution> | ||
| <id>check</id> | ||
| <goals> | ||
| <goal>check</goal> | ||
| </goals> | ||
| <configuration> |
There was a problem hiding this comment.
The JaCoCo check execution isn’t bound to a lifecycle phase (no <phase>), so it won’t run during mvn verify unless invoked explicitly. Bind it to verify (or the intended phase) so the CI step mvn verify actually enforces the 0.90 coverage rule.
| cache: maven | ||
|
|
||
| - name: Run tests with coverage check | ||
| run: mvn verify 2>/dev/null |
There was a problem hiding this comment.
mvn verify 2>/dev/null suppresses all stderr output, which makes test failures / JaCoCo check failures hard to diagnose in CI logs. Prefer leaving stderr intact (or using Maven flags like -B / --no-transfer-progress) so actionable failure details remain visible.
| run: mvn verify 2>/dev/null | |
| run: mvn -B --no-transfer-progress verify |
| jobs: | ||
| bump-version: | ||
| if: "github.event.workflow_run.conclusion == 'success' && !startsWith(github.event.workflow_run.head_commit.message, 'chore: bump version')" | ||
| uses: ./.github/workflows/_bump-version.yml |
There was a problem hiding this comment.
release.yml is triggered by workflow_run, but the reusable workflow _bump-version.yml runs under workflow_call and won’t have access to github.event.workflow_run.* unless you pass it explicitly. As written, _bump-version.yml will check out the repo default ref and may bump/push the wrong branch; add inputs like ref/sha and pass ${{ github.event.workflow_run.head_branch }} / ${{ github.event.workflow_run.head_sha }} here.
| uses: ./.github/workflows/_bump-version.yml | |
| uses: ./.github/workflows/_bump-version.yml | |
| with: | |
| ref: ${{ github.event.workflow_run.head_branch }} | |
| sha: ${{ github.event.workflow_run.head_sha }} |
| check-version: | ||
| if: "github.event.workflow_run.conclusion == 'success'" | ||
| uses: ./.github/workflows/_check-version.yml | ||
|
|
||
| deploy_to_ecr: | ||
| needs: check-version | ||
| uses: ./.github/workflows/_deploy-ecr.yml | ||
| with: | ||
| version: ${{ needs.check-version.outputs.version }} | ||
| secrets: |
There was a problem hiding this comment.
Because cd.yml is triggered by workflow_run, you likely want to deploy the exact commit that CI tested (github.event.workflow_run.head_sha). The reusable workflows invoked via uses: won’t automatically receive the workflow_run payload (they run as workflow_call), so they’ll check out the default branch HEAD unless you pass head_sha (and/or head_branch) as an explicit input and use it in actions/checkout inside the called workflows.
| - name: Check out code | ||
| uses: actions/checkout@v4 | ||
|
|
There was a problem hiding this comment.
This reusable workflow checks out code without a pinned ref. When invoked from cd.yml / release.yml you’ll typically want to run against the triggering workflow_run commit; add an input like sha and set actions/checkout ref: to that value to avoid comparing/deploying a different revision than the CI-tested one.
| while IFS= read -r msg; do | ||
| [ -z "$msg" ] && continue | ||
| if ! echo "$msg" | grep -qiE "$PATTERN"; then | ||
| echo "::error::Invalid commit message: \"$msg\"" | ||
| FAILED=true | ||
| else | ||
| echo "::notice::Valid: \"$msg\"" | ||
| fi | ||
| done < <(git log --no-merges --pretty=format:"%s" "$BASE"..HEAD) | ||
|
|
There was a problem hiding this comment.
On pull_request runs, actions/checkout defaults to the GitHub-generated merge commit, and this loop will validate that merge commit’s subject too (typically starts with "Merge ..."), causing false failures against the Conventional Commits regex. Consider excluding merge commits (e.g., git log --no-merges ...) or checking out the PR head SHA and diffing base.sha..head.sha instead.
| - name: Check out code | ||
| uses: actions/checkout@v4 | ||
| with: | ||
| fetch-depth: 0 | ||
|
|
There was a problem hiding this comment.
The checkout step doesn’t specify a branch/SHA to operate on. Since this workflow is called via workflow_call, it will default to the caller’s ref (likely the repo default branch for workflow_run callers), so the version bump can land on the wrong branch. Add a required ref/sha input and check out that ref here before modifying/committing.
…e test execution Co-authored-by: Copilot <copilot@github.com>
Description
This PR adds diverse CI/CD scripts
What type of PR is this? (check all applicable)
Related Tickets & Documents
Mobile & Desktop Screenshots/Recordings
Steps to QA
Added to documentation?
[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?