2026-04-28 11:09:03 +07:00
2 changed files with 19 additions and 76 deletions
@@ -27,3 +27,22 @@ jobs:
        with:
          go-version-file: go.mod
      - run: go test ./...
+
+  vet:
+    runs-on: linux
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-go@v5
+        with:
+          go-version-file: go.mod
+      - run: go vet ./...
+
+  staticcheck:
+    runs-on: linux
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-go@v5
+        with:
+          go-version-file: go.mod
+      - run: go install honnef.co/go/tools/cmd/staticcheck@2025.1.1
+      - run: $(go env GOPATH)/bin/staticcheck ./...
@@ -1,76 +0,0 @@
-# Design: Issue #18 — Add `go vet` and `staticcheck` to CI
-
-## Context
-Issue #18 requires expanding PR CI validation for this Go repository beyond existing `gofmt` and `go test` checks.
-
-Current state:
- CI is defined in `.gitea/workflows/ci.yml`.
- Existing jobs: `fmt` (`gofmt -l .`) and `test` (`go test ./...`).
- No `go vet` or `staticcheck` step exists.
-
-## Goal
-Add practical baseline static analysis to pull request CI by:
- Running `go vet ./...`.
- Running `staticcheck ./...`.
- Pinning `staticcheck` version in CI for deterministic behavior.
-
-## Non-goals
- Adding `golangci-lint`.
- Refactoring application code unrelated to CI wiring.
- Changing workflow triggers.
-
-## Approved approach
-Use separate CI jobs for `vet` and `staticcheck` while keeping existing `fmt` and `test` jobs unchanged.
-
-### Why this approach
- Keeps changes surgical and easy to review.
- Makes failures explicit per check (better debugging signal than a combined lint step).
- Preserves current CI behavior while extending validation coverage.
-
-## Implementation design
-Modify `.gitea/workflows/ci.yml` only.
-
-### Job: `vet`
- `runs-on: linux`
- Steps:
-  1. `actions/checkout@v4`
-  2. `actions/setup-go@v5` with `go-version-file: go.mod`
-  3. `run: go vet ./...`
-
-### Job: `staticcheck`
- `runs-on: linux`
- Steps:
-  1. `actions/checkout@v4`
-  2. `actions/setup-go@v5` with `go-version-file: go.mod`
-  3. Install pinned staticcheck version:
-     - `go install honnef.co/go/tools/cmd/staticcheck@2025.1.1`
-  4. Run staticcheck:
-     - `$(go env GOPATH)/bin/staticcheck ./...`
-
-## Failure behavior
- CI must fail if `go vet ./...` exits non-zero.
- CI must fail if `staticcheck ./...` exits non-zero.
- Existing `fmt` and `test` failure behavior remains unchanged.
-
-## Verification plan
-Local verification before PR creation:
- `gofmt -l .`
- `go test ./...`
- `go vet ./...`
- `staticcheck ./...` (if tool is available locally)
-
-CI verification through PR run:
- Confirm `fmt`, `test`, `vet`, and `staticcheck` jobs execute on pull requests.
- Confirm non-zero from `vet`/`staticcheck` marks workflow failed.
-
-## Risks and mitigations
- Risk: pinned staticcheck version not present in runner cache.
-  - Mitigation: install in-job via `go install` each run.
- Risk: staticcheck findings on current code block CI.
-  - Mitigation: if encountered, address only findings required to satisfy issue scope.
-
-## Acceptance mapping
- CI fail on vet errors → `vet` job runs `go vet ./...`.
- CI fail on staticcheck errors → `staticcheck` job runs pinned staticcheck binary.
- Existing checks preserved → `fmt` and `test` jobs remain in workflow.
- No `golangci-lint` → not introduced in workflow.