Skip to content

release-golang.yml can tag a Go version that fails tests-golang.yml on macOS, Windows or the live tests #1173

Open

Description

@coderdan

Background

The Go module in this repository (github.com/cipherstash/stack/languages/golang) embeds three WASI guests. A WASI guest is a WebAssembly build of our Rust encryption engine, run from Go. Releases are cut by hand with .github/workflows/release-golang.yml, added in #1167. It builds the guests, commits them on a release-only commit, and pushes a tag such as languages/golang/v0.1.0-alpha.1. Once the Go module proxy (proxy.golang.org) has fetched a version, the version can never change. A release that turns out to be broken can only be fixed by releasing a new version.

The Go module's CI is .github/workflows/tests-golang.yml. It runs:

  • the WASI checks and the Go tests on Linux (wasi-check);
  • go-lint;
  • the Go tests on macOS and Windows (go-binding-cross);
  • the live tests against real CipherStash services (live).

Problem

The release workflow does not check that tests-golang.yml passed for the commit it tags.

Its build job does run the Go tests. They run on Linux only (mise run go:test), against the exact guests being released. Nothing runs these checks before the tag is pushed:

  • the macOS and Windows tests;
  • the live tests;
  • go-lint;
  • the WASI import-surface checks.

So a version can be tagged that fails on macOS or Windows, or against the real service. The version is then permanent.

A simple "did tests-golang.yml pass for this commit?" check does not work, for two reasons:

  1. It often has no run for the commit. tests-golang.yml runs on pull requests and on pushes to main, and only when certain paths change (.github/workflows/tests-golang.yml, the on: block). A main commit that touches no Go or Rust paths has no run.
  2. A pre-release is often cut from a branch with no pull request. The first partner alpha is planned that way, from the unmerged EQL v4 stack. A commit like that has no run either.

A naive check would refuse many valid releases.

Proposal

  1. Use the trigger that already exists. tests-golang.yml has workflow_dispatch (line 76), and none of its jobs is skipped on a dispatch. The release build job could:

    • look for a successful tests-golang.yml run on $GITHUB_SHA (gh run list --workflow tests-golang.yml --commit "$GITHUB_SHA" --status success);
    • refuse with a clear error when there is none. The error should give the command to run first: gh workflow run tests-golang.yml --ref <ref>.

    The check should run before anything is built, next to the version check, so a refusal costs seconds.

  2. Decide whether pre-releases need it. A strict rule for final versions only would keep partner alphas quick. Any version tag is permanent, though, so requiring it for every version is also reasonable. Pick one and write it down in AGENTS.md.

  3. Alternative: the release workflow could call the test jobs itself. That would need tests-golang.yml to become callable (workflow_call), or its jobs to be copied, so it is a bigger change than step 1.

Evidence

Verified:

  • release-golang.yml's build job runs only mise run go:test (Linux) and the guest builds; it reads no other workflow's result.
  • tests-golang.yml path-filters both pull_request and push, and has workflow_dispatch: {}. Its only conditions are needs: wasi-check on two jobs.

Plausible, not checked:

  • That gh run list --commit finds a dispatched run on a branch ref by its head SHA. Confirm this before relying on it.
  • That the live job's credentials are available on a dispatch from any branch. The job goes through .github/actions/require-cs-secrets.

Relationship to other work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    SDKenhancementNew feature or requestgithub-actionsPull request modifies GitHub Actionsneeds-triageMaintainer needs to evaluate the issue

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions