Skip to content

ci: migrate CI to GitHub Actions - #39

Open
fohte wants to merge 6 commits into
masterfrom
fohte/ci-migrate-to-github-actions
Open

ci: migrate CI to GitHub Actions#39
fohte wants to merge 6 commits into
masterfrom
fohte/ci-migrate-to-github-actions

Conversation

@fohte

@fohte fohte commented Aug 31, 2026

Copy link
Copy Markdown

Why

  • CircleCI has stopped running tests, so pull requests can no longer be used to verify changes to the library

What

  • Remove the broken CircleCI config and run tests and e2e tests for every Go module automatically via GitHub Actions
  • Also fix the parts that failed to test under the current Go toolchain
fohte added 6 commits August 31, 2026 19:13
@fohte
cmd/subee: update golang.org/x/tools to fix test panic on newer Go
ead310e 
intent(cmd/subee): unblock running `go test` under current Go toolchains
  as part of the CircleCI to GitHub Actions migration
learned(cmd/subee): golang.org/x/tools v0.0.0-20191017035025-0abb09c987dd
  panics with "internal error: package ... without types was imported
  from ..." under Go 1.26 because go/packages' loader protocol changed
  since that pre-modules-era release
@fohte
ci: migrate from CircleCI to GitHub Actions
9f91e94 
intent(ci): restore a working CI so PRs get tested again — the CircleCI
  config had been broken since the `circleci/golang` Docker Hub images
  it depends on were removed, leaving the README badge permanently red
decision(ci): matrix over every Go module directory instead of a single
  `go test ./...`, since this is a multi-module repo and the root command
  never reached the nested modules
decision(ci): start the Pub/Sub emulator with a plain `docker run` and
  poll the port, since GitHub Actions' `services:` cannot override an
  image's command and the emulator image needs one to actually start
rejected(ci): porting the CLI release job (go-crossbuild/github-release/
  homebrew) and the codecov upload — out of scope, library releases only
  need a tag push and neither had a working badge or was requested
@fohte
engine_test: guard shared test state with a mutex to fix data race
ddea746 
intent(engine_test): let `go test -race` pass reliably now that CI
  actually runs it again
learned(engine_test): handleMessage runs each consumed message/batch in
  its own goroutine by design, so the consumer callbacks in these tests
  can run concurrently; TestEngine masked this by sleeping 6ms between
  messages, but TestEngineWithBatchConsumer's tighter timing let two
  callback invocations race on `cur` and the `resultCh` close, which
  -race reliably caught
@fohte
ci: keep verbose test output and surface emulator logs on failure
683c798 
intent(ci): match the removed CircleCI config's verbosity and make e2e
  failures debuggable from the Actions log alone
decision(ci): keep the Pub/Sub emulator container running (drop --rm)
  and dump its logs only `if: failure()`, since the runner is ephemeral
  anyway so there's nothing to clean up
@fohte
cmd/subee: explicitly import subee in generated code
6f54c45 
intent(cmd/subee): fix TestSubscriberGenerator failing in CI, where it
  passed locally
learned(cmd/subee): generated files never wrote the "github.com/wantedly/subee"
  import themselves, relying on imports.Process (goimports) to guess and
  add it; that guess scans the machine's real $GOMODCACHE regardless of
  the test's own isolated packages.Config.Env, so it silently succeeds
  only on machines that happen to have the module cached already — CI's
  clean cache always misses it
decision(cmd/subee): add the import unconditionally and let imports.Process
  prune it when actually unused, instead of relying on it to add imports
  it can't reliably resolve
@fohte
cmd/subee: fix contradictory example in the subee-import comment
a0d9461 
learned(cmd/subee): the comment's own example (an adapter-less consumer
  using subee.Message) was a case that DOES reference subee, not one
  that doesn't — the file that actually lacks the reference is the
  with-adapter consumer interface, which only deals with the concrete
  message type
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant

@fohte