Repository navigation
Expanded platform support: Consider porting to go or typescript #243
Description
Power PC, Solaris, IBM Mainframe, redhat 5/6 (without a new sku) etc.
Start with an ADR evaluation of platform coverage
{{ message }}
Power PC, Solaris, IBM Mainframe, redhat 5/6 (without a new sku) etc.
Start with an ADR evaluation of platform coverage
Activity
TingluoHuang commentedon Jan 21, 2020
#296
jbergstroem commentedon Jan 29, 2020
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 commentedon Jan 29, 2020
@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 commentedon Jan 30, 2020
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 commentedon Jan 30, 2020
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 commentedon Jan 31, 2020
golangsupported platform: https://github.com/golang/go/wiki/MinimumRequirementsnode.jssupported platform: https://github.com/nodejs/node/blob/master/BUILDING.md#platform-listmyitcv commentedon Feb 12, 2020
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@$versiongo 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 byGOOSandGOARCH.ad-m commentedon Feb 13, 2020
@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 commentedon Feb 13, 2020
@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 commentedon Feb 13, 2020
@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 commentedon Feb 13, 2020
@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 commentedon Feb 13, 2020
Go ahead and create one. I guess here is the best place :)
myitcv commentedon Feb 13, 2020
@bryanmacfarlane raised as #333.
bnoordhuis commentedon Apr 3, 2020
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 commentedon Sep 23, 2020
I would suggest to write a runner in C++ using e.g. Boost.Asio. This should work on almost any platfrom and architecture.
smorimoto commentedon Jan 23, 2021
Any language is fine as long as the platforms we want to support are supported. In any cases, we must make clear paths and move forward if we do this.
edrozenberg commentedon Mar 4, 2021
Since this issue dates to 2019, curious if still planned anytime soon or years away if ever. Considered using this project but got discouraged when I saw .Net is involved. Don't want to make life tougher with unpleasant dependencies. We'll consider using Github's own runner functionality for now rather than using this self hosted project.
hross commentedon Mar 31, 2021
For now we don't have plans to take on rewriting the runner. for reference @edrozenberg this is the code for the github runner itself (hosted and self hosted).
davidchisnall commentedon May 19, 2021
Rewriting the runner is likely to be a lot of work, but it would be beneficial if the the protocol that the runner talks could be cleanly documented. This would allow for third-party implementations for self-hosted pools.
jbergstroem commentedon May 19, 2021
Took the liberty of opening a new issue to track this.
ChristopherHX commentedon May 25, 2021
I successfully reverse engineered their undocumented protocol and used act to write a runner prototype in go.
nektos/act#706
Add GitHub Actions