Add GitHub Actions CI workflow for Go test matrix, linting, and Codecov

[Copilot]

This adds the repository’s missing test automation in GitHub Actions. CI now runs on pushes to master and on pull requests, covering the Go versions in scope, race-enabled tests, coverage reporting, linting, and Codecov upload.

• Workflow coverage

  • Adds .github/workflows/ci.yml
  • Triggers on:
    • push to master
    • pull_request

• Go test matrix

  • Runs tests on Go 1.25 and 1.24
  • Uses race detection and coverage output in the test job

• Coverage upload

  • Uploads coverage.out to Codecov
  • Tags uploads by Go version to keep matrix results distinct

• Linting

  • Adds a dedicated golangci-lint job
  • Uses the Go version from go.mod for lint consistency

• Coverage generation detail

  • Limits coverage profile generation to packages that actually contain tests, avoiding coverage-tool failures from packages without test files

strategy:
  matrix:
    go-version: ['1.25', '1.24']

run: |
  mapfile -t packages < <(go list -f '{{if or .TestGoFiles .XTestGoFiles}}{{.ImportPath}}{{end}}' ./... | sed '/^$/d')
  go test -race -covermode=atomic -coverprofile=coverage.out "${packages[@]}"

[anacrolix]

@copilot check go1.25 is actually required. set go version in go.mod to minimum viable. run CI on go stable and oldstable versions (if minimum version allows this at present). fix lints or modify rules as appropriate

[Copilot]

@copilot check go1.25 is actually required. set go version in go.mod to minimum viable. run CI on go stable and oldstable versions (if minimum version allows this at present). fix lints or modify rule...

Addressed in 348475f. The repo now targets Go 1.24.0 after downgrading only golang.org/x/net to v0.50.0 and golang.org/x/sys to v0.41.0, while CI still tests on 1.25 and 1.24. I also changed the lint job to build golangci-lint under the runner toolchain and run a focused passing ruleset (govet, ineffassign, misspell).

[anacrolix]

@copilot why do you make PRs as drafts? Who do you expect to mark them as ready for review?

[Copilot]

@copilot why do you make PRs as drafts? Who do you expect to mark them as ready for review?

I don’t expect someone else to babysit that. The draft state wasn’t intentional here; unless I’m explicitly waiting on more work, the PR should be ready for review. I don’t have a tool in this environment to flip the PR state, but I’ll treat draft as the exception rather than the default.