Native Go

[nikolaydubina]

Description:

I saw today Node 20 deprecation notice in our CI piplines.

To my surprise major Go CI action is using Typescript?

This is so strange. Why Go ecosystem that is notoriouslty does not even depend on libc to do syscalls now is depending on a dependency/security nightmare JS/Typescript ecosystem?

More to that. Since recently, Typescript itself uses Go. So to build a Go project we depend on something that is itself depends on Go itself to be built! Why we have this extra jump into Typescript land?

Go has notoriously high stability and security of its packages. Minimialism in dependencies.
Typescript/Node is notoriously nightmare. Fiasco after Fisasco. Every year something happens.
Why we are not utilising Go to build CI ecosystem for Go projects?

What are we even doing here.

Justification:

like cmon.

Are you willing to submit a PR?

Yes.

[v-priyagupta108]

Hello @nikolaydubina 👋,

Thank you for this feature request. We will investigate it and get back to you as soon as we have some feedback.

In the meantime, on the Node 20 deprecation notice: setup-go already runs on node24 as of v6.0.0. Released tags are immutable, so if you're pinned to v5 or an older commit SHA you'll still see that warning. Upgrading to actions/setup-go@v6 or @v7 should resolve it.
If you're still seeing it on v6/v7, please share a link to the workflow run where you're seeing it or a minimal reproduction and we'll take a look.

[nikolaydubina]

Here I implemented it. It is farily small. bootstrapping go binary from official distribution, so it is a bit slower than GitHub CDN. might add GitHub CDN later.

https://github.com/ndx-technologies/gh-setup-go

Twitch: https://www.twitch.tv/videos/2856991462

[v-priyagupta108]

Thanks for building this and sharing it, @nikolaydubina.

Worth flagging that this isn't a native Go action, though. Actions only runs JavaScript, Docker, or composite steps, and there's no Go runtime, so a Go binary can't be an entry point on its own. Docker would rule out Windows and macOS, which we need. What you've got is a composite action where bash downloads Go and compiles the binary at runtime, so the Node dependency is swapped for bash, curl, tar, and a go build on every job rather than removed.

On the supply chain side, the distributions we serve are built and checked as part of the actions/go-versions release process and published as immutable release assets.

A couple of other things you'll probably hit: shell: bash is hardcoded and the binary has no .exe, so Windows likely doesn't work, and requiring an exact patch version means no go-version-file or go.mod detection, which is how most people use this.

We're not planning to rewrite this action in Go, but appreciate the effort you put into it.