Description
Description
When adding a sub-package to a function using golang-middleware and Go modules, I'm unable to get it to build. The unit tests fails immediately, then the go build fails if the test step is commented out.
Step 17/29 : RUN go build --ldflags "-s -w" -a -installsuffix cgo -o handler .
---> Running in cd54e2e66fb9
build handler: cannot load github.com/alexellis/vend/vend/handlers: git ls-remote -q origin in /go/pkg/mod/cache/vcs/15c84a3c22a2d4367cca03dcf38500ba216f1f2e95fa3fdd4255f8434c417d89: exit status 128:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Confirm the import path was entered correctly.
If this is a private repository, see https://golang.org/doc/faq#git_https for additional information.
Sample repo
https://github.com/alexellis/golang-middleware-relative-import
The top-level entry-point is main.go
main.go is a module and references a folder "function" which is also a module.
The basic path of a function handler with no other packages seems to work without Go modules, but when adding a sub-package i.e. handlers
and referencing that, the tests and build fail.
main -> function -> handlers (sub-package)
This should have been a basic happy path scenario tested in #24, so I'm surprised to see that this didn't work. Pinging the people who tested / reviewed the PR.
@ewilde @LucasRoesler @bmcstdio @jonatasbaldin @stefanprodan
I imagine this is the same issue for go
and golang-http
also.
When using dep and a vendor folder this can be worked-around so that it works in the container, but not on a local system. The ideal resolution would have OpenFaaS functions with sub-packages working well in an IDE with highlighting and goreturns etc all working fine, and also working in a docker build
.