Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not sure if this is the 'right way' or not, but for a recent Go project, I just scripted the build via

    - name: build
      run: |
        docker run --rm -v \
          "$PWD":/usr/src/my-project \
          -w /usr/src/my-project \
          -e GOOS -e GOARCH \
          golang:1.13 go build -v -o my-project-$GOOS-$GOARCH
      env:
        GOOS: ${{ matrix.os }}
        GOARCH: ${{ matrix.arch }}
(GitHub Actions's build environment already has Docker installed/configured, so there's no setup necessary for "run: docker run" to work.)

I did this explicitly because I didn't want to use that "setup-go" action you linked, which at the time (I haven't doubled checked it recently) didn't support Go 1.13. Far better to me to use the Docker image, which has explicit instructions even for cross-platform compilation in its README, than rely on some weird action setup, in my opinion.



I like this approach as well, though I typically include a `Dockerfile` in my Go projects so my run task is just:

    - name: Build
      run: docker build -t me/image:latest .
      env:
        DOCKER_BUILDKIT: 1
        GOOS: ${{ matrix.os }}
        GOARCH: ${{ matrix.arch }}


Ah, well, the output of what I wrote above isn't actually a Docker image. It ends up writing a cross-compiled binary to the local FS, which I then later attach to a GitHub Release. (The goal was to automatically attach platform binaries to a release once it was made.)

...unless your Dockerfile ends up doing that too? If so I'd be interested to see it if you're willing to share!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: