chore(ci): add GitHub Actions workflow

[spencercjh]

Add CI workflow to run Makefile rules:

• verify job: deps, fmt, lint, test
• build job: build binary and upload artifact
• test-e2e job: run e2e tests with Maven and Gradle matrix

[qodo-code-review]

Review Summary by Qodo

Add GitHub Actions CI workflow for automated verification and builds

✨ Enhancement

Walkthroughs

Description

• Add GitHub Actions CI workflow for automated testing and building
• Verify job runs dependencies, formatting, linting, and tests
• Build job compiles binary and uploads artifact after verification
• E2E tests job runs with Maven and Gradle matrix on build completion

Diagram

flowchart LR
  trigger["Push to main or PR"] --> verify["Verify Job<br/>deps, fmt, lint, test"]
  verify --> build["Build Job<br/>Compile binary"]
  build --> e2e["E2E Tests Job<br/>Maven & Gradle matrix"]
  e2e --> artifact["Upload Artifact"]

Loading

File Changes

1. .github/workflows/ci.yml ⚙️ Configuration changes +105/-0

Complete GitHub Actions CI workflow configuration

• Creates new CI workflow triggered on push to main and pull requests
• Verify job sets up Go 1.24, installs golangci-lint, and runs make targets for dependencies,
 formatting, linting, testing, and building
• Build job depends on verify, sets up Go environment, builds binary, and uploads artifact with
 7-day retention
• E2E tests job depends on build, sets up Go and JDK 17, runs tests with Maven and Gradle matrix
 strategy

.github/workflows/ci.yml

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (5) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Go version mismatch 🐞 Bug ✓ Correctness

Description

CI installs Go 1.24 while the root module declares Go 1.26.0, which can make the workflow fail to
build/test or behave differently than local development. Use go-version-file: go.mod (or update
the pinned version) to keep CI aligned with the module requirement.

Code

.github/workflows/ci.yml[R20-24]

+      - name: Set up Go
+        uses: actions/setup-go@v5
+        with:
+          go-version: "1.24"
+          cache: true

Evidence

The workflow pins Go 1.24 in multiple jobs, but the repository’s root go.mod requires Go 1.26.0,
creating an immediate toolchain mismatch.

go.mod[1-4]
.github/workflows/ci.yml[20-24]
.github/workflows/ci.yml[55-60]
.github/workflows/ci.yml[82-87]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
CI pins Go 1.24, but the repository’s root `go.mod` requires Go 1.26.0. This mismatch can cause `go test`/`go build` and tooling to fail or behave inconsistently.

## Issue Context
The workflow sets up Go in `verify`, `build`, and `test-e2e`. The repo already declares the required version in `go.mod`.

## Fix Focus Areas
- .github/workflows/ci.yml[20-24]
- .github/workflows/ci.yml[55-60]
- .github/workflows/ci.yml[82-87]
- go.mod[1-4]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Fmt/tidy not enforced 🐞 Bug ⛯ Reliability

Description

The workflow runs commands that can modify the working tree (go mod tidy, golangci-lint fmt) but
never fails if they introduce changes, so PRs with untidied modules or misformatted code can still
pass. Add an explicit git diff --exit-code (or switch to check-only modes) after these steps.

Code

.github/workflows/ci.yml[R32-36]

+      - name: Download dependencies
+        run: make deps
+
+      - name: Format check
+        run: make fmt

Evidence

make deps runs go mod tidy and make fmt runs a formatter; the workflow does not check for a
clean repo afterward, so modifications won’t be detected as failures.

.github/workflows/ci.yml[32-37]
Makefile[37-41]
Makefile[65-69]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The CI runs `make deps` (includes `go mod tidy`) and `make fmt` (formats code), but does not verify that these steps didn’t change tracked files. That allows untidied/unformatted PRs to pass without forcing contributors to commit the updates.

## Issue Context
This reduces CI’s effectiveness as a gate for formatting/module hygiene.

## Fix Focus Areas
- .github/workflows/ci.yml[32-37]
- Makefile[37-41]
- Makefile[65-69]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Actions not SHA-pinned 🐞 Bug ⛨ Security

Description

Several third-party actions are referenced by mutable tags (e.g. @v5, @v4), which increases
supply-chain risk if a tag is moved or compromised. Pin actions to immutable commit SHAs (and
optionally use Dependabot to keep them updated).

Code

.github/workflows/ci.yml[R94-103]

+      - name: Setup Maven
+        if: matrix.test-type == 'maven'
+        uses: stCarolas/setup-maven@v5
+        with:
+          maven-version: 3.9.6
+
+      - name: Setup Gradle
+        if: matrix.test-type == 'gradle'
+        uses: gradle/actions/setup-gradle@v4
+

Evidence

The workflow uses tag-based references for external actions; tags are not immutable.

.github/workflows/ci.yml[26-30]
.github/workflows/ci.yml[94-103]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow references third-party actions via mutable tags (e.g., `@v5`, `@v4`, `@v6`). This is a supply-chain risk because tags can change.

## Issue Context
Pinning to a commit SHA makes CI runs reproducible and reduces the blast radius of compromised upstream action releases.

## Fix Focus Areas
- .github/workflows/ci.yml[26-30]
- .github/workflows/ci.yml[94-103]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. E2E may timeout cold 🐞 Bug ⛯ Reliability

Description

E2E tests involve Maven/Gradle runs and are bounded by 5-minute timeouts in test code; without
dependency caches, cold runners may approach these limits and become flaky. Consider adding
Maven/Gradle caches (or increasing timeouts if appropriate).

Code

.github/workflows/ci.yml[R88-105]

+      - name: Set up JDK 17
+        uses: actions/setup-java@v4
+        with:
+          java-version: "17"
+          distribution: "temurin"
+
+      - name: Setup Maven
+        if: matrix.test-type == 'maven'
+        uses: stCarolas/setup-maven@v5
+        with:
+          maven-version: 3.9.6
+
+      - name: Setup Gradle
+        if: matrix.test-type == 'gradle'
+        uses: gradle/actions/setup-gradle@v4
+
+      - name: Run E2E tests (${{ matrix.test-type }})
+        run: make test-e2e

Evidence

The e2e tests and generator both default to 5-minute timeouts, while the workflow does not configure
any explicit Maven/Gradle dependency caching around the make test-e2e step.

.github/workflows/ci.yml[88-105]
integration-tests/e2e_test.go[39-40]
integration-tests/e2e_test.go[212-213]
internal/extractor/spring/generator.go[152-155]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
E2E tests and the Spring generator default to 5-minute timeouts. Without Maven/Gradle dependency caches in CI, cold runs may be slow enough to hit these limits and cause flaky failures.

## Issue Context
The workflow runs `make test-e2e` in a matrix but does not configure explicit caches for build-tool dependencies.

## Fix Focus Areas
- .github/workflows/ci.yml[71-105]
- integration-tests/e2e_test.go[39-40]
- integration-tests/e2e_test.go[212-213]
- internal/extractor/spring/generator.go[152-155]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. Redundant verify build 🐞 Bug ➹ Performance

Description

verify builds the binary and then the build job rebuilds it again to upload the artifact,
increasing CI time without adding coverage. Consider removing the build step from verify (keeping
it in build) to match the PR description and reduce duplication.

Code

.github/workflows/ci.yml[R44-46]

+      - name: Build binary
+        run: make build
+

Evidence

The workflow runs make build in both verify and build jobs; since jobs run on separate
runners, this is duplicated work.

.github/workflows/ci.yml[44-46]
.github/workflows/ci.yml[61-63]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The binary is built twice: once in `verify` and again in `build`. This increases CI duration without adding additional validation.

## Issue Context
PR description indicates `verify` should run deps/fmt/lint/test, while `build` should build/upload.

## Fix Focus Areas
- .github/workflows/ci.yml[32-46]
- .github/workflows/ci.yml[47-69]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[Copilot]

Pull request overview

Adds a GitHub Actions CI workflow to automate verification, building, artifact upload, and end-to-end testing for the project’s Makefile-driven pipeline.

Changes:

• Introduces a verify job running make deps, make fmt, make lint, make test, and make build.
• Adds a build job to build the binary and upload it as an artifact.
• Adds a test-e2e job intended to run e2e tests with a Maven/Gradle matrix and JDK 17.

Comments suppressed due to low confidence (1)

.github/workflows/ci.yml:105

• The E2E matrix currently runs make test-e2e unchanged for both maven and gradle, so the exact same Go e2e test suite runs twice. Either remove the matrix (and likely the Maven/Gradle setup steps, since the tests use mvnw/gradlew wrappers), or make the matrix meaningful by passing the selected tool into the test command and filtering tests accordingly.

        test-type: [maven, gradle]
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: "1.24"
          cache: true

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: "17"
          distribution: "temurin"

      - name: Setup Maven
        if: matrix.test-type == 'maven'
        uses: stCarolas/setup-maven@v5
        with:
          maven-version: 3.9.6

      - name: Setup Gradle
        if: matrix.test-type == 'gradle'
        uses: gradle/actions/setup-gradle@v4

      - name: Run E2E tests (${{ matrix.test-type }})
        run: make test-e2e

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

.github/workflows/ci.yml:110

• The E2E matrix sets test-type: [maven, gradle], but both legs run the exact same make test-e2e command, so each run executes all E2E tests and the matrix just duplicates work. If the intent is to split Maven vs Gradle coverage, pass a selector into the test command (e.g., go test ... -run TestE2E_Maven... vs TestE2E_Gradle..., or an env var consumed by the tests/Makefile) so each matrix leg runs only its subset.

        uses: actions/checkout@v4

      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: "1.26"
          cache: true

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: "17"
          distribution: "temurin"

      - name: Setup Maven
        if: matrix.test-type == 'maven'
        uses: stCarolas/setup-maven@v5
        with:
          maven-version: 3.9.6

      - name: Setup Gradle
        if: matrix.test-type == 'gradle'
        uses: gradle/actions/setup-gradle@v4

      - name: Run E2E tests (${{ matrix.test-type }})
        run: make test-e2e

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 8 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

PR metadata says this change is only adding CI, but this PR also includes non-CI changes (provider name constants, factory switch updates, e2e test change, and go.mod edit). Please confirm these are intended to be in this PR (or split them) so reviewers can track non-CI behavior changes separately.

[Copilot]

This step is configured to run golangci-lint --help and sets verify: false, so it doesn't actually perform any linting/config validation and its intent is unclear. If the goal is to lint, let the action run with the repo config; if the goal is only to install the binary for make fmt/make lint, use an explicit install step (or an install-only mode) instead of invoking --help.

Suggested change

	- name: Setup golangci-lint
	uses: golangci/golangci-lint-action@v7
	with:
	version: v2.10
	args: --help
	verify: false
	- name: Install golangci-lint
	run: |
	go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest

[Copilot]

E2E job also uses go-version: stable, which can make runs non-reproducible (especially for go test and module resolution) compared to the pinned Go version in go.mod/build job. Prefer go-version-file: go.mod or the same pinned Go version across jobs.