golang-continuous-integrationlisted

# Go Continuous Integration Create the smallest pipeline that enforces the repository's actual support and release policy. Do not copy a generic workflow without reconciling it with the project. ## Inspect before designing Read: - go.mod, go.work, tool pinning, generated-code instructions, and supported platforms; - existing workflows, repository instructions, Makefile or task runner, and local verification commands; - release and container configuration; - branch protection assumptions and whether pull requests can come from forks. Infer neither the supported Go matrix nor the release process from the current local toolchain. If compatibility is undocumented, surface the choice rather than inventing a matrix. ## Build a minimal check graph A typical pull-request pipeline may include: 1. Build or compile the packages and commands relevant to the project. 2. Run unit tests with the repository's ordinary flags. 3. Run formatting, vet, lint, generated-code, or module-tidiness checks only when the repository defines the corresponding policy. 4. Run integration tests in a separate job when they need services, credentials, longer timeouts, or platform-specific setup. 5. Run vulnerability analysis when govulncheck is already pinned or available, or when the user asks to add it. Use the race detector where CGO, platform support, runtime, and the project's risk profile make it useful; it need not run on every matrix entry. Coverage is evidence, not a universal quality thresho