ci: run go build, vet and test on pull requests to develop

[pastoriniMatheus]

Description

Adds .github/workflows/ci.yml, which runs go build ./..., go vet ./... and go test ./... on every pull request targeting develop.

Today no workflow in this repository is triggered by pull_request. The only Go check that exists anywhere in the pipeline is go build ./cmd/evolution-go/, inside sync-releases.yml — it runs after the merge, against the generated output, and in the last 6 pushes it did not execute at all (the job dies at "Clone target repo" and "Verify build" shows as skipped).

go build alone would not be a real gate: it never compiles _test.go files. Measured on develop @ 706c9a4, with a test file importing a module path that does not resolve:

command	exit
go build ./...	0 — does not catch it
go vet ./...	1 — no required module provides package …
go test ./...	1

Remove the probe and all three return to 0. go vet is the step that earns this workflow: it is the one that compiles test files, which is the most common way an outside contribution breaks.

Two smaller points, both deliberate:

• go-version-file: go.mod instead of a literal version, so the toolchain cannot drift from what the module declares. (For reference, sync-releases.yml currently pins go-version: '1.24' while go.mod declares go 1.25.0; GOTOOLCHAIN=auto silently downloads 1.25.0 to cover the gap. That is a separate one-line change and is not included here.)
• submodules: recursive is required, not optional: go.mod has replace go.mau.fi/whatsmeow => ./whatsmeow-lib, so without the submodule the build cannot resolve the module. The submodule is public, so no token and no fetch-depth: 0 are needed.

Why develop only, and not main

develop and main have no common ancestor in this repository (git merge-base origin/main origin/develop returns nothing; 481 files differ). A workflow added on develop therefore never exists on main, and pull_request evaluates the workflow from the merge ref — so listing main in the triggers would be a dead line, not extra coverage.

That also means this workflow covers 17 of the 54 currently open PRs (the ones based on develop). The other 37 target main, which is a generated distribution branch — that is a separate problem and needs a contribution-docs change, not a CI change.

Related Issue

No single issue; this comes out of a triage pass over the open PR queue. The concrete case that motivated it is #117 (Postgres connection pool leak), which sat open without any automated Go signal at all.

Type of Change

• Other: CI / repository infrastructure — no application code is touched.
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Performance improvement

Testing

• Both directions proven locally. RED: with a _test.go importing an unresolvable path, go vet and go test exit 1 while go build exits 0 (table above). GREEN: with the probe removed, build / vet / test all exit 0 — 1 package with tests (pkg/utils), 50 without, 0 failures.
• Baseline taken on a clean tree, develop @ 706c9a4, submodule at its pinned SHA 0923702. Nothing in this repository is currently failing, so the job starts green rather than importing pre-existing debt.
• The real mirror content also passes. Ran the same three commands against origin/main @ 9337afc — the branch that carries the obfuscated pkg/core/c0.go — and all three exit 0 with 4 test packages. Obfuscation is not an obstacle to CI.
• YAML validated by parser: 1 job (go), 5 steps, triggers pull_request + push on [develop].
• Verified on a real runner. This PR triggered its own workflow (run 34930905279): event=pull_request, conclusion=success, headSha=273383c2 (the commit in this PR), all six steps green in 1m37s. That settles the three items that were open when this PR was written: the cgo/libwebp build works on ubuntu-latest with no apt-get, setup-go resolved the toolchain from go.mod without incident, and this fork PR ran without needing "Approve and run workflows". Cache behaviour across runs is still a single-data-point unknown — if repeat runs stay around four minutes, a manual actions/cache is the follow-up.

Screenshots (if applicable)

n/a

Checklist

• My code follows the project's style guidelines — comments in the workflow are in English and limited to what the YAML cannot state on its own.
• I have performed a self-review of my code.
• I have tested my changes thoroughly — both directions locally, and green on a real runner via this PR's own run.
• Any dependent changes have been merged and published — none; this adds one file and changes nothing existing.

Additional Notes

This is signal, not a gate, until someone enables it as one. develop currently reports protected: false, /protection returns 404 and rulesets is empty. Without the go check marked as a required status check, a red run blocks nothing. That matters here because the repository already carries ignored red: sync-releases.yml has failed its last 7 runs since 2026-05-06, and manager-v2.yml / voip-integration.yml ran 12 times on pull_request with 100% failure ("workflow file issue"). The go context now exists and has reported success on this PR, so it can be selected as a required check right away. Doing so needs repository admin, which I do not have — I would ask a maintainer to turn it on when this merges, otherwise this becomes the fourth red nobody looks at.

Out of scope, on purpose:

• gofmt — 8 files on develop are currently unformatted (measured against the LF blobs in git, not a CRLF checkout). One of them is pkg/whatsmeow/service/whatsmeow.go, the exact file PR fix(whatsmeow): reuse a single capped sqlstore container (fixes Postgres connection leak) #117 modifies, so adding a formatting gate now would fail the PR this work is trying to unblock. The right order is: merge fix(whatsmeow): reuse a single capped sqlstore container (fixes Postgres connection leak) #117, then gofmt -w the 8, then add the check.
• make check / make lint — check runs fmt, which rewrites files rather than verifying them, and lint invokes golangci-lint, which is not installed and has no .golangci.yml in the repo (the target exits 1 by design). Either would fail every PR for tool reasons.
• golangci-lint, an OS/version matrix, an explicit CGO_ENABLED, a manual actions/cache — each is either already covered by defaults or needs a decision that should not ride along in this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_017ijukEy5wKHnKg7NemEPk9

[sourcery-ai]

Reviewer's Guide

Introduces a single Ubuntu-based CI job for pull requests and pushes to develop, using the module-declared Go version and required submodules before running build, vet, and test across the repository. The workflow is intended to provide automated signal for develop-based contributions; branch protection and required-status-check configuration remain outside the PR.

Sequence diagram for the Go CI workflow

sequenceDiagram
    participant GitHub
    participant Runner as UbuntuRunner
    participant Checkout as actions/checkout
    participant SetupGo as actions/setup-go
    participant Go as GoToolchain

    GitHub->>Runner: Trigger pull_request or push to develop
    Runner->>Checkout: checkout with submodules: recursive
    Checkout-->>Runner: Repository and whatsmeow-lib available
    Runner->>SetupGo: Read go.mod
    SetupGo-->>Runner: Install declared Go toolchain
    Runner->>Go: go build ./...
    Go-->>Runner: Build result
    Runner->>Go: go vet ./...
    Go-->>Runner: Vet result including test-file compilation
    Runner->>Go: go test ./...
    Go-->>Runner: Test result

Loading

File-Level Changes

Change	Details	Files
Added a GitHub Actions workflow that validates Go changes on the develop integration branch and its pull requests.	Triggers on pull requests targeting develop and pushes to develop. Checks out recursive submodules required by the local module replacement. Derives the Go toolchain version from go.mod. Runs go build, go vet, and go test across all packages. Cancels superseded runs for the same ref.	.github/workflows/ci.yml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

Sourcery assessment

Approved.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook