Composite actions are not mentioned

[AlekSi]

README says:

By default, GitHub Actions expects actions to be written in Node.js. For other languages like Go, you need to provide a Dockerfile

There is a third option now – composite actions. Given that all GitHub runners have Go preinstalled, that provides an easier alternative to building and publishing Docker images or using nodejs shims.

[sethvargo]

That blog post is pretty dope - using node.js to shell out to Go is a nifty idea. Do you want to write up a short blurb in the README?

[AlekSi]

What I tried to say is that there is no need for both Node.js and Docker now: https://docs.github.com/en/actions/creating-actions/creating-a-composite-action
Here is an example: https://github.com/FerretDB/github-actions/tree/main/extract-docker-tag Just normal Go code and small metadata file. No need to use Node.js, build Docker containers, etc.

[sethvargo]

I might be misunderstanding, but wouldn't someone who uses the composite action need to have setup-go as a previous step though?

My other concern with this approach is that it gives up some of the performance and security benefits of having a single-static binary.

[AlekSi]

I might be misunderstanding, but wouldn't someone who uses the composite action need to have setup-go as a previous step though?

All GitHub runners have Go preinstalled. So that should not be a problem unless one tried to use the latest version of Go on the day of its release or use self-hosted runner without Go installed.

My other concern with this approach is that it gives up some of the performance and security benefits of having a single-static binary.

That's all true. But go run is fast enough (in absolute numbers) and secure enough (for many cases) even with fetching go-githubactions from the proxy. And this approach might be much more convenient.

So, I guess we want to mention all options?

[sethvargo]

All GitHub runners have Go preinstalled.

Interesting - I thought you had to use actions/setup-go. TIL.

But go run is fast enough (in absolute numbers) and secure enough (for many cases) even with fetching go-githubactions from the proxy.

I think my bigger concern is if the module pulls in many, many other dependencies. That could dramatically increase load times. I guess that would really be the responsibility of the author though - they could always vendor so the deps are included in the clone.

So, I guess we want to mention all options?

Yea, I think we might want to shorten the README a bit and provide all options, potentially mentioning trade-offs.