Use Makefile targets in GitHub Actions workflow

[Copilot]

The CI workflow called go commands directly, creating drift from the Makefile used for local development. Aligning both eliminates that discrepancy.

Changes

• .github/workflows/build.yml
  • go mod download → make deps
  • go test -v ./... → make test
  • Inline go build block → make build GOOS=linux GOARCH=amd64

- name: Download dependencies
  run: make deps

- name: Run tests
  run: make test

- name: Build plugin (Linux AMD64)
  run: make build GOOS=linux GOARCH=amd64

On ubuntu-latest (linux/amd64), make build GOOS=linux GOARCH=amd64 is a native build — no Docker involved, output is identical to the previous inline command.

Original prompt

Update the GitHub Actions workflow .github/workflows/build.yml to use the Makefile instead of calling go commands directly.

Replace the following steps:

1. "Download dependencies" (run: go mod download) → run: make deps
2. "Run tests" (run: go test -v ./...) → run: make test
3. "Build plugin (Linux AMD64)" (the inline go build block) → run: make build GOOS=linux GOARCH=amd64

The rest of the workflow (checkout, setup-go, upload-artifact, release job) should remain unchanged.

Note: make build with GOOS=linux GOARCH=amd64 on an ubuntu-latest runner is a native build (no Docker needed), so this is a drop-in replacement.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: In dem Repository ist aus dem Hello-World-Template ein Makefile vorhanden, in der GitHub-Action wird dieses Makefile aber anscheinend nicht aufgerufen, sondern ein anderen Befehl zum Builden des Plugins. Ist das sinnvoll bzw. korrekt und könnte stattdessen auch das Makefile aufgerufen werden?

Assistant: Ist es sinnvoll/korrekt? Ja, technisch korrekt – aber es gibt eine wichtige Einschränkung:

Das make build-Target erkennt automatisch Host- und Ziel-OS/Arch. Im CI-Kontext (ubuntu-latest, Linux/amd64 → Linux/amd64) wäre das ein nativer Build und würde denselben go build-Befehl ausführen. Die Workflow-Schritte tun also effektiv das Gleiche wie make build GOOS=linux GOARCH=amd64.

Warum wurde das Makefile trotzdem nicht verwendet?
Das ist ein typischer Überbleibsel aus dem Hello-World-Template: Das Makefile wurde für lokale Entwicklung erstellt, der Workflow wurde separat (manuell oder per Template) gepflegt und nicht auf das Makefile abgestimmt.

Könnte man das Makefile verwenden? Ja, problemlos. Die deps-, test- und build-Steps lassen sich direkt ersetzen:

- name: Download dependencies
  run: make deps

- name: Run tests
  run: make test

- name: Build plugin (Linux AMD64)
  run: make build GOOS=linux GOARCH=amd64

Einziger Vorbehalt: make build ruft bei Cross-Compilation (also wenn Host ≠ Target) Docker auf. Im CI-Fall linux/amd64 → linux/amd64 ist das aber ein nativer Build, Docker wird nicht benötigt. Die Umgebungsvariablen-Logik im Makefile und die direkte go build-Variante im Workflow produzieren identische Ergebnisse.

Empfehlung: Makefile im Workflow verwenden – das verhindert Drift zwischen lokalem Build und CI.

User: Okay, bitte passe die GitHub Action entsprechend an

Assistant: I'm waiting for your response to the tool call dialog to proceed with updating the workflow.

This pull request was created from Copilot chat.

---

⌨️ Start Copilot coding agent tasks without leaving your editor — available in VS Code, Visual Studio, JetBrains IDEs and Eclipse.