Native support for pure Go actions

Following on from discussion in https://github.com/actions/runner/issues/243#issuecomment-585764955

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

Start by reviewing the linked discussion and the runner's handling of uses: directives, using the example .github/workflows/test.yml as the expected workflow shape. Compare the requested Go module resolution and go run flow with the current runner behavior; done means pure Go actions can run natively without a NodeJS wrapper or separately installed Go toolchain.