x/build: publish periodic tip binary builds for CI tooling

[qmuntal]

It would be useful for the Go project to publish periodic binary builds of Go tip, so CI tooling can make testing against a recent development version of Go as easy as:

- uses: actions/setup-go@vN
  with:
    go-version: tip

The main motivation is to make it easier for Go package maintainers to find compatibility problems before a major Go release ships. Today, projects that want early signal can use golang.org/dl/gotip, which is very flexible: it can build the latest commit, a specific older commit on the main branch, a development branch, or even a CL still in review.

However, gotip works by downloading source and building Go. For many GitHub Actions users, that is enough friction that they do not add tip testing to their CI matrix. Pre-built tip archives would make the common case much easier: “test against a reasonably recent Go development build and report failures as non-fatal signal.”

There is related interest on the actions/setup-go side: actions/setup-go#21. That action can already install released Go versions from binary archives, but supporting go-version: tip well likely needs an upstream source of official or semi-official tip build artifacts and machine-readable metadata.

There was prior discussion of nightly or periodic pre-release builds in #29205. At the time, one blocker was that the Go release process was still too manual. Since then, much of that automation work has landed, which may make periodic tip binary builds more feasible now.

This issue is not necessarily asking for a formal proposal immediately. Since this is mostly in x/build / release infrastructure territory, it may be enough to discuss the shape here first and promote it later only if needed.

A possible target state:

• The Go project publishes binary archives for a selected recent tip commit on a regular cadence, perhaps nightly.
• The builds are available for the same or a useful subset of supported release platforms.
• A machine-readable manifest exposes the latest available tip build, commit hash, build time, archive URLs, and checksums.
• CI integrations such as actions/setup-go can resolve go-version: tip to the latest published tip build.
• The builds are clearly framed as development snapshots, not supported Go releases, and not covered by the Go security policy.
• gotip remains the tool for arbitrary commits, branches, and CLs.

Example CI usage using setup-go:

strategy:
  matrix:
    go-version: ['1.25.x', 'tip']

continue-on-error: ${{ matrix.go-version == 'tip' }}

steps:
  - uses: actions/checkout@vN

  - uses: actions/setup-go@vN
    with:
      go-version: ${{ matrix.go-version }}

  - run: go test ./...

@golang/release @dmitshur

[mvdan]

However, gotip works by downloading source and building Go. For many GitHub Actions users, that is enough friction that they do not add tip testing to their CI matrix.

To add a bit of color to this: downloading and building Go at master can easily take over a minute, which is rather slow for a CI setup step. I personally start feeling development pain if CI takes more than five minutes in total, for example.

One alternative is caching, but that's not a good solution. The caching would be per-project, when in fact you would have hundreds or thousands of projects all building the same tip commits on a daily basis. And caching isn't free either; downloading and later uploading hundreds of megabytes on GitHub's actions/cache still takes a number of seconds.

Downloading and extracting a prebuilt archive is by far the fastest option.

A machine-readable manifest exposes the latest available tip build, commit hash, build time, archive URLs, and checksums.

One nit: I would also offer a direct archive URL for the latest tip build, such as .../tip-latest.tar.gz, so that those simply wanting the latest build can fetch it directly without needing to first fetch and process the "latest" manifest. This can save some amount of shell scripting and an extra roundtrip.

[gabyhelp]

Related Issues

• x/build: ensure there are accessible ways to test Go pre-release versions in common CI systems #38773
• x/build: configure dashboard builders to test the same configurations that will be shipped in binary releases #46900

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[jakebailey]

This would also be useful for doing bisects, a la mozbisect or vscode-bisect which can bisect all the way to a commit, or at least to a range.

[mvdan]

@jakebailey I fully agree, with the caveat that this would require making sure that every commit up to "latest tip" is built. For the CI use case that @qmuntal mentions, building the latest tip commit periodically (e.g. daily) is enough. We could probably do every commit given that usually that's 10-50 per day.

[prattmic]

I too thought of bisection before I got to Jake's comment.

Asking out of ignorance, does GitHub Actions provide any tooling that would make it easy to automate bisection if we published every commit? Or would that always need to be a separate tool?

[jakebailey]

I'm not sure anything exists that's that generic; all bisect tools I know about (including the one I made for TS!) are bespoke to their projects.

I can also imagine this being powered by GOTOOLCHAIN and the builds appearing in the modcache, thought that's probably quite disk heavy 😄