mangos CI Keeps GitHub Actions Go Setup Current
mangos is a pure Go implementation of the SP messaging protocols used by nanomsg style systems. This week is small but useful: the project moved its Go setup step to actions/setup-go@v7 across the main CI workflows, which keeps Linux, macOS, Windows, and coverage checks on the same current GitHub Actions base.
CI matrix now uses setup go v7
The recent activity is one focused maintenance commit, the setup go v7 bump. It changes one line in each affected workflow. The action pin moves from actions/setup-go@v6 to actions/setup-go@v7.
That is not a runtime change to mangos. No protocol code moved. No transport behavior changed. The value is in keeping the project test harness close to the GitHub Actions platform it runs on.
For a Go library that promises broad platform support, this kind of change is boring in the correct way. Contributors want a pull request to fail because the code is wrong, not because CI is pinned to an older setup action that starts drifting from current hosted runner behavior.
The repeated setup block still looks familiar:
- name: Set up Go
uses: actions/setup-go@v7
with:
go-version: stable
id: go
The important point is that the version changed while the intent stayed the same. The workflows still ask GitHub for stable Go, or for the stable and oldstable matrix where that coverage matters.
Platform checks stay broad
mangos supports TCP, IPC, inproc, WebSocket, TLS, and WebSocket TLS transports. That makes the operating system matrix more than decoration. Socket behavior, file path handling, and Windows process details can all expose bugs that a single Linux run would miss.
The Linux workflow still runs go build -v . and go test ./... across stable and oldstable. The darwin workflow does the same for macOS. The Windows workflow keeps the Windows runner in the same pattern.
That consistency matters for contributors. If a change touches transports or tests under the project test tree, the same basic build and test shape runs on each hosted runner. There is less room for a platform to be quietly weaker than the others.
Concrete checks that did not change:
go get -v -t -d ./...go build -v .go test ./...- Go version matrix with
stableandoldstable
The repo README says mangos follows the same support matrix as Go, with current Go and the prior release guaranteed. The workflows mirror that policy. The setup action update keeps the mechanism fresh without changing the policy.
Coverage remains a first class signal
The coverage workflow also moved to actions/setup-go@v7. This job is slightly different from the platform workflows. It runs across ubuntu-latest, macos-latest, and windows-latest, then produces a coverage profile with go test -coverpkg.
That gives the project two useful signals. The normal workflows confirm basic build and test health against stable and oldstable Go. The coverage workflow checks whether the broader package set is still exercised enough to report useful coverage.
There is a practical detail here. Coverage jobs often grow fragile because they touch test execution, profile output, and a third party upload action in one place. The mangos change keeps the Go setup action current while leaving the Codecov upload path, file name, and coverage flags alone.
For maintainers, that is a low noise update. If coverage breaks after this change, the suspect list stays short. The Go setup action changed. The coverage command did not.
What this means for users
Most mangos users do not need to change anything. Application code importing go.nanomsg.org/mangos/v3 is not affected by this commit. The module still declares go 1.22 in go.mod, and this CI activity does not alter dependencies or exported APIs.
The change is more relevant if you maintain a fork, carry local patches, or use mangos as a reference for testing Go libraries across hosted runners. In that case, the useful lesson is simple: keep the setup action aligned across every workflow, not just the one that fails first.
If your fork has copied these workflows, compare these files before opening a large cleanup pull request:
The small scope is also a useful review pattern. One commit updated one dependency pin across all matching workflow files. That is easy to audit. It avoids mixing CI action maintenance with test rewrites, dependency changes, or Go version policy changes.
How to prepare
If you contribute to mangos, expect CI behavior to be the main thing to watch after this update. A failure in the next few pull requests is more likely to be runner or action behavior than a changed mangos API, because no library code changed here.
Fork maintainers should check for copied pins to actions/setup-go@v6. Use the same update everywhere or leave it everywhere until you can test it. A half updated matrix is annoying because it makes platform failures harder to compare.
Operators using released mangos packages can treat this as repo hygiene. The project is keeping its validation path current. That is not exciting, but for a networking library with platform specific edges, it is the kind of maintenance you want to see before the next real code change lands.