Support go modules #194
Support go modules #194
Conversation
**What** - Add support for nested go modules by supporting the GO_REPLACE.txt file and the build args for GO111MODULE and GOFLAGS Signed-off-by: Lucas Roesler <roesler.lucas@gmail.com>
| RUN CGO_ENABLED=${CGO_ENABLED} GOOS=linux \ | ||
| go build --ldflags "-s -w" -a -installsuffix cgo -o handler . && \ | ||
| go test $(go list ./... | grep -v /vendor/) -cover | ||
| go build --ldflags "-s -w" -a -installsuffix cgo -o handler . |
There was a problem hiding this comment.
Should the $GOFLAGS arg be used here?
There was a problem hiding this comment.
This ENV variable is read by the go command automatically https://golang.org/cmd/go/#hdr-Environment_variables
| WORKDIR /go/src/handler | ||
| COPY . . | ||
|
|
||
| # Add user overrides to the root go.mod, which is the only place "replace" can be used | ||
| RUN cat function/GO_REPLACE.txt >> ./go.mod || exit 0 |
There was a problem hiding this comment.
I find the GO_REPLACE pattern a bit confusing, have you consider merging go.mod instead? That way the function writer still has a regular go.mod that can be linted / validated. This project seems like it could do the trick: https://github.com/brendanjryan/modmerge
There was a problem hiding this comment.
Or maybe even go the multi-module approach and have the main code can be a module and the function code a different one? If a package name is enforced we might not even need the replace. https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories has an overview of that approach.
There was a problem hiding this comment.
This multi-module approach is what we are doing here, but ... go does not follow replaces in modules, so if you need to use a replace in your function handler module, it will not be respected in the parent template module. This GO_REPLACE is a way for us to explicitly allow overriding the replaces in the parent function module.
|
The approach is being tested and is documented. This was socialised on GitHub and slack with no concerns raised. This PR copies the approach Concatenating a go.mod may work but we should try not to introduce mandatory dependencies that would slow down the build. |
There was a problem hiding this comment.
Approved. Thank you @LucasRoesler 🙏 and @rberrelleza for taking a look over the work.
|
@LucasRoesler just to check, do you need to update the README and the docs page for the classic go template? |
Description
Add support for nested go modules by supporting the GO_REPLACE.txt file and the build args for GO111MODULE and GOFLAGS.
The version of Go is upgraded to the latest major version: 1.13
This largely replicates the module support and structure of the go-middleware-template
Motivation and Context
Which issue(s) this PR fixes
Fixes #189
How Has This Been Tested?
I have created a demo repo to show that the template works as expected. https://github.com/LucasRoesler/gomodule-template-test
It specifically show how the nested module support works. I have also manually tested the simpler flat module and non-module mode.
Types of changes
Impact to existing users
Existing functions should continue to work as expected. The only changes should be controlled by the build arg
Checklist:
git commit -s