Actions support for multiple go version go1.10 ... go1.12

[dougnukem]

depends on https://github.com/cedrickring/golang-action/pull/3

Manages support for multiple golang versions in the repo so they can be referenced by github repo URL in ,

• New autogenerated actions are in subdirectories based off the parent Dockerfile as the template
  • go1.10
  • go1.11
  • go1.12

The benefit of having these in the repo itself it means that users that want to import that action can do it by github URL and don't have to rely on adding / maintaining special go1.10/go1.11/go1.12 branches and tags. This is similar to how Golang manages multiple versions of go in their official Docker images:

• https://github.com/docker-library/golang

For example now to use a specific version of go users can reference it as:

action "ci" {
  uses="cedrickring/golang-action/go1.12@1.1.1"
  ...
}

This PR also updates the Docker tag and publish behavior.

See here for examples of tagged images published to Docker hub:

• https://cloud.docker.com/repository/docker/dougnukem/golang-action/tags

Docker images are published and tagged as follows:

• LABEL version="1.2.3" indicates MAJOR.MINOR.PATCH semantic version
• Tag the action docker image represented in the root Dockerfile
  • golang-action:1.2.3 - for users that want to pin it to the exact version
  • golang-action:1.2 - for users that want to pin it to a specific minor version
    • I feel like this mode makes the most sense as users will likely want patch updates (security fixes, bug fixes) that don't have impact on compatibility or features
  • golang-action:1 - for users that want to pin it to a specific major version

We then build and publish specific go version variants for users that want to pin the specific go version they are using:

• golang-action:1.2.3-go1.10
  • golang-action:1.2-go1.10
  • golang-action:1-go1.10
• golang-action:1.2.3-go1.11
• golang-action:1.2.3-go1.12

Next Steps

• Figure out github release and tagging process
  • Discuss how / when a major/minor/patch version is incremented
    • Could be anytime there's a merge to master at least the patch version should be bumped (we could do that automatically as part of the @master Actions workflow, not sure thats right though, maybe it can check if a git tag for the current LABEL version="1.2.3" exists and if it does increment the patch version, commit that and build and tag it

[cedrickring]

@dougnukem you need to rebase now

[cedrickring]

So to bump the version, I just have to call version-bump-<major|minor|patch> right?

I like that approach. Makes updating the action quite easy while still having support for all go versions! 😄

[dougnukem]

@cedrickring rebased

Yes for releases you should be able to just run:

$ make version-bump-minor
$ git commit -a -m "update minor version"
# Do a github release

We could even look into doing a more robust one:

# runs bump-version-<major | minor | patch>
# commits changes
# Tags build and creates a github release and tag with $VERSION
$ make release-version-minor