Add a target to prepare go.mod for a specified gotify version

[eternal-flame-AD]

Currently, .travis.yml makes sure that the go.mod in the repo is fit with the master branch of gotify in every build. Thus every automated build is made against the master branch and thus might not work with the latest release of gotify server.

I suggest adding a update-go-mod target to update the go.mod to fit a certain gotify version:

update-go-mod: create-build-dir
	wget -LO ${BUILDDIR}/gotify-server.mod https://raw.githubusercontent.com/gotify/server/${GOTIFY_VERSION}/go.mod
	gomod-cap -from ${BUILDDIR}/gotify-server.mod -to go.mod
	rm ${BUILDDIR}/gotify-server.mod || true
	go mod tidy

So in .travis.yml to can do this to build for different versions of gotify.

- before-deploy:
  - GO111MODULE=off go get gopkg.in/mikefarah/yq.v2
  - >
      for TARGET in v1.3.0 v1.3.1 master; do
        TARGET_GO_VERSION=$(curl -fsSL "https://raw.githubusercontent.com/gotify/server/$TARGET/.travis.yml" | yq.v2 read - go\[0\]);
        eval "$(gimme ${TARGET_GO_VERSION})";
        make GOTIFY_VERSION=${TARGET} update-go-mod;
        make build;
      done

In this way, the built plugin would be guranteed to have the same go toolchain version and depencencies with the corresponding gotify/server target.

[jmattheis]

The docker images already contain the go tool chain, using gimme there to change the version doesn't really have an effect, at least not for the build.

Maybe the release build for gotify/server must also build the gotify/build docker images with the same version as the gotify/server release. Then we could enable plugin authors to build for different gotify/server versions. What do you think?

[jmattheis]

Or we could tag the docker images with the golang version like you said in gotify/website#6 (comment).

[eternal-flame-AD]

Yeah, I definitely think we should tag images after took chain versions. As for how to find out which release is built with which took chain would be a little difficult to implement, a simpler solution would be only to build using the newest toolchain, which, from my point of view, would satisfy most users' needs. You decide it:)

[jmattheis]

Yeah only building for the newest tool chain should be enough. If we do this update-go-mod thingy you proposed in the first comment, then it is still unclear which versions the current newest tool chain supports. I guess we should provide a plugin support cli which does this gomod-cap thingy and runs the docker images.

[eternal-flame-AD]

Could you please explain more clearly what the cli tool you proposed does? According to "which does this gomod-cap thingy and runs the docker images" it sounds like invoking gomod-cap followed by a docker run?

[jmattheis]

Yes it is basically this, but it also chooses the right docker image to build the plugin.

I've a better idea, we could add a file to the gotify/server repo named DOCKER_BUILD_VERSION. This file contains the version of the docker image that was used to build the release.
Plugins then use this file to obtain the version that should be used for building plugins.

[eternal-flame-AD]

I think it could be done with bash only, so we don't need to write another program just for this?

[jmattheis]

Jup

[jmattheis]

Fixed in #3