Runner: Expanded platform support: Consider porting to go or typescript

[bryanmacfarlane]

Power PC, Solaris, IBM Mainframe, redhat 5/6 (without a new sku) etc.

Start with an ADR evaluation of platform coverage

[TingluoHuang]

296

[jbergstroem]

I reckon sticking with Node.js is the way to go since most of the action landscape is written in javascript; meaning that even if you would "switch .NET for go", you would be restricted to where node.js can run.

[bryanmacfarlane]

@jbergstroem - yeah, we're mostly restricted to running where node. However, if there's a platform that go runs on but node doesn't it could still support run: command lines and scripts. So I would say if we chose go, then any delta would be possible but a degraded experience.

[jbergstroem]

So I would say if we chose go, then any delta would be possible but a degraded experience.

Makes sense but I think it would be a confusing user story. All documentation now would have to take this exception into regard; "works except here", "works only there". I would personally prefer a consistent functionality across runners.

[bryanmacfarlane]

It would be covered in one place - the runner download experience. That's would also be part of the design and analysis when we choose to start this work.

[TingluoHuang]

golang supported platform: https://github.com/golang/go/wiki/MinimumRequirements
node.js supported platform: https://github.com/nodejs/node/blob/master/BUILDING.md#platform-list

[myitcv]

Great to see this. I've experimented with pure Go GitHub actions using a thin NodeJS wrapper - from a dependency perspective Go is a great story (as well as being cross-platform).

At the bottom of the blog post I sketched out what v1 of a pure Go solution might look like:

• uses: directives reference main packages, so $package@$version
• create a temporary Go module to reference the action
• use proxy.golang.org for resolution
• go run $package (which has the side effect of authenticating modules vs sum.golang.org and including all module version information in the resulting binary)

This disadvantage of v1 is that it requires an uncached build step for each action.

But that could easily be fixed in v2 where you have a simple internal GitHub service that cached and served pre-built cross-platform binaries for $package@$version. Then you would elide the build time, replacing it with a very fast CDN-speed binary download parameterised by GOOS and GOARCH.

[ad-m]

@myitcv, in terms of providing cache for built Go modules, it is worth pointing out that in GitHub Actions currently even Docker images do not have any cache. With each use of the Docker action, the container image is built from the beginning.

[myitcv]

@ad-m I'll defer to you/others on how things currently work 😄

My suggestion re caching was, as I tried to indicate via the "v2", a suggestion of how an initial first cut "v1" could be improved further down the line. Absolutely not critical for v1.

[bryanmacfarlane]

@myitcv - let's keep considerations of supporting go actions natively in another issue. I want to keep this issue focused on the runner code.

[myitcv]

@bryanmacfarlane 👍absolutely. Is there an open issue I should follow? Or would you like one created? If so, another issue in this repo or elsewhere?

[bryanmacfarlane]

Go ahead and create one. I guess here is the best place :)

[myitcv]

@bryanmacfarlane raised as https://github.com/actions/runner/issues/333.

[bnoordhuis]

If there are problematic platforms or architectures for Node.js, that's something I can look into.

We (the Node.js project) are interested in using Actions for our CI matrix. We already test on a fairly wide range of platforms and architectures (z/os, aix, freebsd, os390, ppc64, etc.)

[aholler]

I would suggest to write a runner in C++ using e.g. Boost.Asio. This should work on almost any platfrom and architecture.