externally configured Go version for automation support

[jmhodges]

I've got a GitHub Action I wrote to update the Go versions in my various configuration files[1]. Especially, for my security projects, I'd like an auditable but automated way to keep the Go versions I use up to date.

(Using a .x version number isn't enough because doing that wouldn't kick off new builds when a new version is released and it's difficult to audit when a new Go version was brought in.)

But, unfortunately (and totally understandably from a security perspective!), GitHub Actions can't modify integration configs. So, I've got a plan to keep my Go versions in a file outside of my workflow configs, have my workflows read in that file and use it for go_version, and then have my tool update that external file.

Would y'all be open to me posting a PR to make that an explicitly supported thing in setup-go? Say, reading a file in something like .github/versions/go.yml or similar?

[1] https://github.com/jmhodges/ensure-latest-go

[jmhodges]

My setup-go config now looks like:

    - name: Read Go versions
      run: echo "##[set-output name=go_version;]$(cat .github/versions/go)"
      id: go_versions
    - name: Set up Go
      uses: actions/setup-go@v1
      with:
        go-version: ${{ steps.go_versions.outputs.go_version }}
      id: go

Example PR that came from it: jmhodges/howsmyssl#267

It'd be nice to get this baked in. The cat inside it means I can only support one version at a time (I believe) and with a more standard support, we could fix that

[radeksimko]

Having an option like this would also allow interoperability with goenv which stores local version in .go-version file in the root of the repo.

    - name: Set up Go
      uses: actions/setup-go@v1
      with:
        go-version-from-file: .go-version

Picking up the version implicitly from there would be even better, but I suppose that would be better job for a more scoped Action with goenv, rather than generic Go one?

At least it seems that there is no precedent for version managers in official setup-language Actions.

[bryanmacfarlane]

@jmhodges on the set output, note that you should use :: syntax. ## was deprecated. See here: https://github.com/actions/toolkit/blob/master/docs/commands.md

@radeksimko - nice idea. Since go-version input is a string, I may just overload that and do special handling for the value .go-version

[jmhodges]

Unfortunately, that regex deal wouldn’t give us an auditable version. It’d pick up whatever was the latest version when it happened to run, instead of when told to bump it. There’d be no way to track the PR it came in, etc

[hazcod]

@jmhodges : how I do it is I extract the Go version to use out of my Docker containers, print it and put it in a GitHub Actions variable. It works with dependabot for automatic updates that way.

[hazcod]

For reference my GitHub Action as seen on iron-go-project:

name: benchmark
on: pull_request

jobs:
  gobench:
    name: benchmarking
    runs-on: ubuntu-latest
    steps:
      -
        uses: actions/checkout@v2
      -
        id: vars
        run: |
          echo ::set-output name=go_version::$(grep '^FROM go' .github/go/Dockerfile | cut -d ' ' -f 2 | cut -d ':' -f 2)
          echo "Using Go version ${{ steps.vars.outputs.go_version }}"
      -
        name: Setup go
        uses: actions/setup-go@v2
        with:
          go-version: ${{ steps.vars.outputs.go_version }}

My file .github/go/Dockerfile:

FROM golang:1.14.1

And keeping the file updated automatically in .github/dependabot.yml:

version: 2
updates:
- package-ecosystem: docker
  directory: "/.github/go"
  schedule:
    interval: daily
    time: '04:00'
  open-pull-requests-limit: 10
  target-branch: dev

[ccremer]

I'm using this:

jobs:
  dist:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Determine Go version from go.mod
      run: echo "GO_VERSION=$(grep "go 1." go.mod | cut -d " " -f 2)" >> $GITHUB_ENV
    - uses: actions/setup-go@v2
      with:
        go-version: ${{ env.GO_VERSION }}

So I only have to maintain go.mod. Only works if you don't need matrix builds ofc :)

But it would be nice if this action could do that on its own, e.g. have a property go-mod-path: go.mod

[MichaelCurrin]

Thanks @ccremer . Came here to see if reading from go.mod was a feature or request but glad to see a snippet for a workaround. ⭐

I've added that snippet to my Go / GH Actions cookbook section, with a link back here - Setup Go cookbook.

I also did a dive into syntax and examples for both $GITHUB_ENV and the outputs approaches and documented here - Persist.

[MichaelCurrin]

Thanks @hazcod for sharing your snippet and iron project. The CI flows there are extensive and I can use in my own projects. I've added a link in my own template to your template.

Would you consider turning issues on to make it easier to discuss before making a PR?

[hazcod]

@MichaelCurrin Thank you! Enabled issues.

[Sergey-Murtazin]

Hi @jmhodges ! Sorry for the late response!
Could you please clarify if the issue is still actual for you?
Thanks!

[radeksimko]

@Sergey-Murtazin Speaking for myself and some of my colleagues, this is still actual.

FYI There is also a PR addressing this problem #62 which was raised in July 2020. Would there be interest in merging it, or is there any particular reason not to merge it?

[jmhodges]

Yeah, I'm still having this problem.

[bflad]

I believe this can be closed now that v3 and v3.1.0 now include the go-version-file input from #62 🎉

Reference: https://github.com/actions/setup-go/releases/tag/v3.1.0

[marko-zivic-93]

Hello guys,
As @bflad said, I will close this issue now, due to the fact that it is resolved. If you have any comments or concerns, feel free to leave them here or to create a new issue.

[jmhodges]

Ah, shoot, go-version-file not being able to specify a patch level means it won't work for me.

This is a bummer because I was hoping dependabot could help me here. (Though, dependabot's gomod setting seems to not have a setting to touch the go version in go.mod anyhow)

[IvanZosimov]

Hi, @jmhodges 👋 In your case, instead of specifying path to go.mod file in the input go-version-file you can specify path to the go file that you're using in your projects. In this way you can just keep the go file up to date and setup-go action will use full semantic version (including patch version) out of that file.

If you have any questions, feel free to ask me 📟

Cheers!

[bflad]

I was able to verify that go-version-file: '.go-version' with those file contents being 1.17.8 was able to work as expected, setting up Go 1.17.8 for the job.