Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native support for pure Go actions #333

Open
myitcv opened this issue Feb 13, 2020 · 6 comments
Open

Native support for pure Go actions #333

myitcv opened this issue Feb 13, 2020 · 6 comments
Labels
Runner Feature Feature scope to the runner

Comments

@myitcv
Copy link

myitcv commented Feb 13, 2020

Following on from discussion in #243 (comment)

Describe the enhancement

Native support for pure Go actions.

Go is a great choice for actions for a number of reasons, including:

  • cross-platform
  • using Go modules via proxy.golang.org and sum.golang.org solves most/all (citation required) of the existing software dependency issues
  • fast and readily cache-able
  • ...

In a recent blog post I experimented with pure Go GitHub actions using a thin NodeJS wrapper. That experiment worked well; GitHub Actions have generous concurrency limits, fast startup times, and solid cross-platform runners.

However:

  • Go needs to be installed in every workflow using such Go actions
  • having to create a wrapper for each action is awkward
  • we are not relying on proxy.golang.org for resolution of the action itself

This issue is therefore a request that GitHub Actions add native support for Go actions, thereby solving all of the above problems (and possibly others).

Code Snippet

At the bottom of the blog post I sketched out what v1 of a pure Go solution might look like, from the user's perspective:

# .github/workflows/test.yml
# ...
    - name: Display a greeting
      uses: github.com/myitcv/myfirstgoaction@v1.0.0
      with:
        name: Helena

In practice this would mean, from the runner's perspective:

  • uses: directives reference main packages, so $package@$version (where $version is a full semver version)
  • creating a temporary Go module to reference the action
  • using 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)

A disadvantage of this bare-bones v1 is that the first use of every action in a workflow results in cache miss: module or build cache and build caches start from cold. But that could easily be fixed in v2 with a simple internal GitHub service that cached and served pre-built cross-platform binaries for $package@$version. That would obviate the download and build time, replacing it with a very fast CDN-speed binary download parameterised by GOOS and GOARCH.

Additional information

n/a

cc @bryanmacfarlane @mvdan @rogpeppe

@bryanmacfarlane
Copy link
Member

bryanmacfarlane commented Feb 13, 2020

One architectural note is that the runner has a goal of being self-contained and package the runtime it uses to run actions. It can update it itself and there's scenarios around running actions in containers while the runner is in the host etc. For example, in the action yaml, it says node12: scriptPath which makes it clear that node12 is the runtime and there's no compat surprises as things drift. So, the runner packages node (and actually a musl version of node for alpine) as script runtime for actions. We also build n times so not a problem.

I think if we did this, it would mean we package the go binary in the runner and the action would be an actions.yml and *.go files that are run via go run?

We would also need to create an actions/toolkit which is go centric. The toolkit is tiny helpers around the envvar conventions etc. so not a big deal to knock out. Note that right now, dependencies like that are self contained in the action (folks use ncc to webpack it into the action). We want to avoid reliability issues and security issues with deps drifting. So the action is self contained.

All of these are possible to solve. I'm just providing some background here and our scenarios and goals.

@bryanmacfarlane
Copy link
Member

Also adding an argument to do this. if we go after broader platform support for the runner, then allowing go actions would expand the platforms of actions at the same time. Absent that, you end up with a degraded experience on the delta platforms (run: works and scripts work, don't use actions).

@myitcv
Copy link
Author

myitcv commented Feb 14, 2020

@bryanmacfarlane

All of these are possible to solve. I'm just providing some background here and our scenarios and goals.

Thanks very much for providing the background and context, very useful.

One architectural note is that the runner has a goal of being self-contained and package the runtime it uses to run actions

With the Go compatibility promise, we know that we should1 always be able to compile an action using the latest stable Go version. The author can specify an expected language version in their go.mod, but this will always be less than or equal to the latest stable version at any given point in time, and in any case only affects language features available.

In my opinion the ultimate goal here is to have zero runtime requirements for pure Go actions; that is what I was hinting at with my v2 proposal. Each action can be cross-compiled ahead of time (and served by some caching service) into a binary for the runner's operating system and architecture (GOOS and GOARCH in Go terms). Zero runtime requirements for pure Go actions means a very lean runner.

That said, a first cut v1 of native Go action support could use go run as I mention above, adding the requirement that Go be available on the runner (a requirement that would disappear with v2).

Hence I don't think we need/want a Go action author to specify a Go version in the action.yml, because ultimately the concept of a runtime will/should disappear.

We want to avoid reliability issues and security issues with deps drifting

Totally agree. Using modules with proxy.golang.org and sum.golang.org we will achieve exactly that, modulo one proviso I cover below.

We would also need to create an actions/toolkit which is go centric.

There is already a first cut of such a package: github.com/sethvargo/go-githubactions. Clearly there is benefit in GitHub defining and owning such a package. There was also some discussion about package name and import paths in sethvargo/go-githubactions#2 FWIW.

Outstanding questions/details

  • modules should be required: it seems reasonable to expect that all pure Go actions should be modules-based
  • require complete go.{mod,sum} files: it also seems reasonable to require that an action's module's go.{mod,sum} files are complete. That is to say, no changes are required to either when installing the main package that is the action. This then ensures that we will have reproducible, authenticated builds (because the act of building the action should not require resolving any dependencies not already described by the action's module's go.mod, and the go.sum should completely satisfy any authentication checks)
  • cgo: arguably this falls outside of the definition of "pure Go actions" so it's probably safe to conclude this is out of scope. Anyone looking to use Go actions that use cgo should fallback to installing Go (because they should not assume it will be available on the runner), install any C dependencies, then build/run the action. This doesn't seem unreasonable

1 modulo the very limited caveats in the linked doc

@TingluoHuang TingluoHuang added runner Runner Feature Feature scope to the runner and removed enhancement New feature or request runner labels Jun 6, 2020
@gliptak
Copy link

gliptak commented Oct 15, 2020

#689

@AlekSi
Copy link

AlekSi commented Jan 6, 2022

While not directly related to this issue, composite actions provide a better alternative for actions written in Go to building Docker images or using NodeJS wrapper.

@sethvargo
Copy link

... We would also need to create an actions/toolkit which is go centric.

@bryanmacfarlane I'd be happy to donate https://github.com/sethvargo/go-githubactions to GitHub if that ends up being a major blocker to implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Runner Feature Feature scope to the runner
Projects
None yet
Development

No branches or pull requests

6 participants