ci: migrate CI from Travis to GitHub Actions and add a Go workflow set

Abierto
  • ¿Algo no está bien?
#96 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
github-actions, go
Área
ci-cd, devops

Línea de trabajo

Start with .travis.yml, go.mod, and go.work, then review the referenced workflows in backblaze-labs/b2-mcp and related issues #92–#95. Run the existing Go checks to confirm the reported vet failures and package coverage gaps. Done means Travis is replaced, the requested workflows and repository settings are in place, and the CI and live workflow meet the stated acceptance criteria.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

ci

Migrate blazer's CI to GitHub Actions and build out a Go-appropriate workflow set. Today the only CI config is .travis.yml, which targets go: tip on master only, runs go run internal/bin/cleanup/cleanup.go as a before_script, then go test -v ./base ./b2 ./x/... and go vet -v ./base ./b2 ./x/.... Travis no longer runs for this repository and there is no .github/ directory, so nothing is verified automatically (the only PR checks are Snyk). go vet ./... currently fails on master at x/consistent/consistent_test.go:156 and :161 (Fatalf from a non-test goroutine), and the internal/, bin/b2keys and examples/ packages are never built or tested by CI.

The workflow set below is modelled on backblaze-labs/b2-mcp/.github/workflows (test.yml, codeql.yml, contract.yml, smoke.yml, mutation.yml, docs.yml, publish.yml, release-tag.yml, quality-keeper.yml), keeping what makes sense for a Go library and dropping the npm, container and MCP specifics. It can land as one PR or several, but the first PR must replace .travis.yml.

Workflows to add:

  • ci.yml (push to the default branch and pull_request): go build ./..., go vet ./..., gofmt -l . must be empty, go mod tidy -diff, go mod verify, and a lint job (golangci-lint or staticcheck). A test job with go test -race -shuffle=on -coverprofile over ./... on a matrix of Go versions (the go directive in go.mod plus the latest stable) and operating systems (ubuntu, macos, windows), with coverage uploaded as an artifact or summary. A job that builds and tests the bin/b2keys workspace module explicitly, since it is a separate module in go.work. A cross-compile smoke job (GOOS/GOARCH including linux/386 and linux/arm) to catch 32-bit issues such as the int size truncation in base. Fix the two existing go vet failures in the same PR so the job is green on day one.
  • A conformance-summary (or equivalent) aggregate job that depends on all required jobs, so branch protection needs a single required check, as in b2-mcp.
  • security jobs: govulncheck ./... on every PR plus a weekly schedule (new advisories land against unchanged code), CodeQL for Go (codeql.yml with push, PR and weekly cron), and zizmor for the workflows themselves (tracked in #93; add the job here or immediately after).
  • test-live.yml (the b2-mcp contract.yml and smoke.yml equivalents): runs the credentialed integration suites in b2/integration_test.go and base/integration_test.go, which read B2_ACCOUNT_ID and B2_ACCOUNT_KEY (align the names with the cross-repo standard B2_APPLICATION_KEY_ID and B2_APPLICATION_KEY while doing this, and add B2_MASTER_KEY_ID and B2_MASTER_KEY only if a test needs them). Triggered by workflow_dispatch, a nightly or weekly schedule, and workflow_call so a release workflow can require it. Runs in a protected GitHub environment holding the secrets, never on pull_request from forks, with a guard job that fails closed when secrets are missing. It must run internal/bin/cleanup/cleanup.go before and after (the current before_script) so leaked <account>-b2-tests-* buckets do not accumulate, and use a concurrency group so two runs never share an account at once.
  • fuzz.yml (optional, weekly or nightly): short go test -fuzz runs for any fuzz targets, such as the file name escape/unescape functions in base/strings.go, with failing inputs committed to testdata/fuzz.
  • bench.yml (optional, advisory): go test -bench with benchstat against the base branch, never blocking.
  • mutation.yml (optional, advisory, weekly): a Go mutation testing tool such as gremlins on base and b2, reporting only, mirroring the advisory mutation workflow in b2-mcp.
  • docs.yml (optional): go doc and example compile checks on PRs; pkg.go.dev renders documentation automatically, so no deploy job is needed.
  • release.yml (tag-triggered v*) and a release-tag request workflow: verify the tag matches CHANGELOG.md, is reachable from a green default-branch commit, runs the full gate plus the live test workflow as a pre-release gate, then creates the GitHub Release with notes taken from the changelog. Details are in the RELEASE.md issue (#94). Do not publish from a workstation.
  • dependabot.yml (or Renovate) for gomod and github-actions with grouped updates and a weekly schedule, plus CODEOWNERS and a pull request template.

Hardening rules to apply to every workflow:

  • permissions: contents: read at the top, widening per job only where needed; pin third-party actions to full commit SHAs; use actions/setup-go with its built-in module and build cache (no separate actions/cache); set persist-credentials: false on checkout; no secrets in logs.
  • Dependabot PRs must never run CI. Every workflow with a pull_request trigger guards each job with if: ${{ github.actor != 'dependabot[bot]' && github.event.pull_request.user.login != 'dependabot[bot]' }}. Workflows without a pull_request trigger (schedule, tag and dispatch only) need no guard.
  • Add a branch protection definition (as branch-protection-main.json does in b2-mcp) requiring the aggregate CI job, and use the new default branch name once #92 lands. A required check that is skipped can block merge, so make sure the aggregate job handles skipped jobs explicitly.

Acceptance: .travis.yml is deleted, ci.yml is green on the default branch and required by branch protection, go vet ./..., go test -race ./... and govulncheck ./... pass in CI, the live workflow has run successfully at least once from a protected environment and leaves no leaked buckets, and every workflow follows the hardening rules above.

Related: #93 (zizmor), #92 (rename master to main), #94 (RELEASE.md), #95 (SECURITY.md).

Lenguaje dominante
Go
Estrellas
66
Forks
18
Merge medio
1 d 10 h
PR fusionados (30 d)
132

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Backblaze/blazer

Todos los issues de Backblaze/blazer

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.