cedrickring / golang-action

A GitHub Action to run Go commands

IMPORTANT: This action will no longer be maintained by myself and thus will not support versions newer than Golang 1.16. I highly recommend using the offical actions/setup-go action which does exactly the same as this action (+ with some more features). Originally this action was helpful when there was the requirement to properly place go projects in the $GOPATH. As this is no longer needed, setting up the proper go version is all you need. However I will kindly review and approve PRs with bugfixes only.

Golang Action

This Action allows you to run Go commands with your code. It will automatically setup your workspace (~/go/src/github.com/<your-name>/<repo>) before the command is run.

How to use

Create a workflow.yaml file in .github/workflows with the following contents:

on: push
name: My cool Action
jobs:
  checks:
    name: run
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master

    - name: run
      uses: cedrickring/[email protected]

If no args are specified and a Makefile is detected, this action will run make. Otherwise go test and go build will be run. To run a custom command, just use:

steps:
- name: Run custom command
  uses: cedrickring/[email protected]
  with:
    args: make my-target

If your repository's import name is different from the path on GitHub, provide the import name by adding an environment variable IMPORT=import/name. This may be useful if you have forked an open source Go project:

steps:
- name: Run with custom import path
  uses: cedrickring/[email protected]
  env:
    IMPORT: "root/repo"

To use Go Modules add GO111MODULE=on to the step:

steps:
- name: Go Modules
  uses: cedrickring/[email protected]
  env:
    GO111MODULE: "on"

If your go project is not located at the root of the repo you can also specify environment variable PROJECT_PATH:

steps:
- name: Custom project path
  uses: cedrickring/[email protected]
  env:
    PROJECT_PATH: "./path/in/my/project"

To use a specific golang version (1.10, 1.11, 1.12, 1.13, 1.14, 1.15), defaults to the latest version:

steps:
- name: Use Go 1.11
  uses: cedrickring/golang-action/[email protected]

golang-action's Issues

Support go modules if a `go.mod` is present

Go modules is looking to be the standard tool for managing dependencies and will be built into the go build toolchain.

• https://github.com/golang/go/wiki/Modules

The action could support go modules if the action detects go.mod

If a repository has modules it is expected to run the build outside the $GOPATH, otherwise it has to inject environment variables to force the go tooling to use modules by default GO111MODULES=on.

Invoke the go command in a directory outside of the $GOPATH/src tree, with a valid go.mod file in the current directory or any parent of it and the environment variable GO111MODULE unset (or explicitly set to auto).

Go team is planning on deprecating the $GOPATH in go1.13 and making GO111MODULES=on by default.

Alternatively this could just be left to users defining their GO111MODULE in a Makefile or build script.

go 1.13 entrypoint.sh not set as an executable

I was having issues running cedrickring/golang-action/[email protected] in my workflow, and I think it has to do with entrypoint.sh not being set as an executable script but as a write/read file

Go dep vendored tests are failing

For some reason after this commit, the tests are failing again:
f03f0f8

Run: https://github.com/cedrickring/golang-action/runs/79343982

@dougnukem some ideas?

Dep with vendored dependencies failing `dep check`

When running the test case with a Go project with vendored dependencies and a Gopkg.toml/Gopkg.lock we are getting errors when the action tries to test it and runs:

• dep check - verify /vendor matches the Gopkg.lock

https://github.com/cedrickring/golang-action/runs/74952504

# vendor is out of sync:
golang.org/x/text: hash of vendored tree not equal to digest in Gopkg.lock

### FAILED Test Go Dep Vendor 14:10:18Z (41.75s)

See notes/discussion: #2 (comment)

For now we can disable that default support in this Action until we resolve the issue.

Deprecate old go versions

This repo should be aligned with the official Go release policy.

Each major Go release is supported until there are two newer major releases

Only the latest 2 versions will be supported and are available in a release. Old Go versions can still be used with previous release tags (e.g. 1.x.x) but won't get any support.

Suggestion for semver tag and release convention to use `v1.1.1`

This is a minor nitpick but with semantic versioning in an SCM like git the standard advice says to name it v${major}.${minor}.${patch}

• https://semver.org/spec/v1.0.0.html#tagging-specification-semvertag

This sub-specification SHOULD be used if you use a version control system (Git, Mercurial, SVN, etc) to store your code. Using this system allows automated tools to inspect your package and determine SemVer compliance and released versions.

When tagging releases in a version control system, the tag for a version MUST be “vX.Y.Z” e.g. “v3.1.0”.

The first revision that introduces SemVer compliance SHOULD be tagged “semver”. This allows pre-existing projects to assume compliance at any arbitrary point and for automated tools to discover this fact.

Ideally we could name the github releases and tag are:

• v1.1.0
• v1.1.1

In terms of release branches I think its fine to call it something like:
releases/v1.1

• patch versions v1.1.0 and v1.1.1 are tagged from this release branch (and hotfixes can be cherry-picked on to this release branch)

You also could do a 'just-in-time' release branch model where the tag is done on master and only when you need to specifically hotfix do you create the release branch:

# need to hotfix release `v1.2.0`
$ git checkout tags/v1.2 -b releases/1.2
# cherry-pick some merge commit
$ git cherry-pick -m 1 xyzabc
# Update Docker label version etc
$ make version-bump-patch 
$ git commit -a -m "Update version to 1.2.1"
$ git tag v1.2.1

For docker image tags I think the convention for semver is to have the following combinations of tags:

• https://medium.com/@mccode/using-semantic-versioning-for-docker-image-tags-dfde8be06699
  

# Assume version: 2.5.3
- cedrickrin/golang-action:latest - this is the most recent built docker image version (its fine to never include this as relying on :latest is bad practice)
-  cedrickrin/golang-action:2 - relying on major version this should be pinned to latest major version and backwards compatible for any changes to minor/patch
-  cedrickrin/golang-action:2.5 - relying on specific major/minor version
-  cedrickrin/golang-action:2.5.3 - relying on specific absolute version

I think the ideal situation is users depend on a specific major version e.g. cedrickrin/golang-action:2 and get the benefit of passively upgrading for bug/security fixes in any minor/patch versions while depending on the major version not having any backwards incompatible changes.

Test all versions in a workflow

We should test each version to work properly before creating a new release.

This should include:

• Build the image
• Run the image with proper workspace, environment variables