ci: migrate CI from Travis to GitHub Actions and add a Go workflow set
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 15/100
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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 andpull_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 withgo test -race -shuffle=on -coverprofileover./...on a matrix of Go versions (thegodirective ingo.modplus the latest stable) and operating systems (ubuntu, macos, windows), with coverage uploaded as an artifact or summary. A job that builds and tests thebin/b2keysworkspace module explicitly, since it is a separate module ingo.work. A cross-compile smoke job (GOOS/GOARCHincludinglinux/386andlinux/arm) to catch 32-bit issues such as theintsize truncation inbase. Fix the two existinggo vetfailures 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. securityjobs:govulncheck ./...on every PR plus a weekly schedule (new advisories land against unchanged code), CodeQL for Go (codeql.ymlwith push, PR and weekly cron), andzizmorfor the workflows themselves (tracked in #93; add the job here or immediately after).test-live.yml(the b2-mcpcontract.ymlandsmoke.ymlequivalents): runs the credentialed integration suites inb2/integration_test.goandbase/integration_test.go, which readB2_ACCOUNT_IDandB2_ACCOUNT_KEY(align the names with the cross-repo standardB2_APPLICATION_KEY_IDandB2_APPLICATION_KEYwhile doing this, and addB2_MASTER_KEY_IDandB2_MASTER_KEYonly if a test needs them). Triggered byworkflow_dispatch, a nightly or weeklyschedule, andworkflow_callso a release workflow can require it. Runs in a protected GitHub environment holding the secrets, never onpull_requestfrom forks, with a guard job that fails closed when secrets are missing. It must runinternal/bin/cleanup/cleanup.gobefore and after (the currentbefore_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): shortgo test -fuzzruns for any fuzz targets, such as the file nameescape/unescapefunctions inbase/strings.go, with failing inputs committed totestdata/fuzz.bench.yml(optional, advisory):go test -benchwithbenchstatagainst the base branch, never blocking.mutation.yml(optional, advisory, weekly): a Go mutation testing tool such asgremlinsonbaseandb2, reporting only, mirroring the advisory mutation workflow in b2-mcp.docs.yml(optional):go docand example compile checks on PRs; pkg.go.dev renders documentation automatically, so no deploy job is needed.release.yml(tag-triggeredv*) and arelease-tagrequest workflow: verify the tag matchesCHANGELOG.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 theRELEASE.mdissue (#94). Do not publish from a workstation.dependabot.yml(or Renovate) forgomodandgithub-actionswith grouped updates and a weekly schedule, plusCODEOWNERSand a pull request template.
Hardening rules to apply to every workflow:
permissions: contents: readat the top, widening per job only where needed; pin third-party actions to full commit SHAs; useactions/setup-gowith its built-in module and build cache (no separateactions/cache); setpersist-credentials: falseon checkout; no secrets in logs.- Dependabot PRs must never run CI. Every workflow with a
pull_requesttrigger guards each job withif: ${{ github.actor != 'dependabot[bot]' && github.event.pull_request.user.login != 'dependabot[bot]' }}. Workflows without apull_requesttrigger (schedule, tag and dispatch only) need no guard. - Add a branch protection definition (as
branch-protection-main.jsondoes 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).
- Lingua principale
- Go
- Stelle
- 66
- Fork
- 18
- Merge medio
- 1g 10h
- PR unite (30g)
- 132
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Backblaze/blazer
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Bucket.Attrs never returns ReplicationConfig: replication configuration is write-onlyForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
test: skip the fuzz non-vacuity guard when replaying a single seedForse già presa @ffumero2003 l’ha presa 5 giorni fa. Apertatesting
Backblaze/blazer#330 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Backblaze/blazer
Issue simili
-
needs-triage typo
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
llm-d-incubation/llm-d-scaling-manager#122 ·
I maintainer di solito rispondono entro 1 giorno
-
good first issue severity: low tech-debt
Difficoltà 2/5 Mezza giornata Idoneità per principianti 75/100
TMHSDigital/subenum#329 ·
I maintainer di solito rispondono entro 1 giorno
-
[Bug] Backend summarize min() / max() panics when a field has no numeric valuesForse già presa @weng5e l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
grafana/grafana-infinity-datasource#1832 ·
I maintainer di solito rispondono entro 1 giorno
-
tech-debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
GillMacedo/godebugdiff#13 ·