Hello,
On Wed, Apr 3, 2019 at 3:49 PM David Riley <fraveyd...@gmail.com> wrote:
> A few things. Responses inline.
>
Will answer inline aswell
>
> > I have a Makefile does some simple tasks for building, it creates a
> tarball of my code directory and starts a docker build -t .... job.
>
> Why make a tarball? You'll get a lot more mileage out of just copying the
> files from the Docker context, which Docker is already tarring up to pass
> around anyway. You'll get fewer surprises that way.
>
To be honest I failed to test COPY and realize it does a recursive copy of
all files and subdirectories to the image layer.
> In our Dockerfiles, we generally have the following as preamble (we also
> add some non-root permissioning, which is more complex than you really need
> right now):
>
> # Provide arguments for the module name (required) and the
> # optional module proxy for hermetic builds
> ARG MOD_NAME=modname
> ARG GOPROXY
> ENV GOPROXY ${GOPROXY}
>
> # Set a variable for our working directory (make sure it matches
> # the module name)
> ENV D $HOME/build/$MOD_NAME
> RUN mkdir -p $D
> WORKDIR $D
>
> # Copy go.sum/go.mod and warm up the module cache (so that this
> # rather long step can be cached if go.mod/go.sum don't change)
> COPY go.* $D/
> CMD go mod download
>
I think this is a quite clever solution, to put the dependency download in
its own layer. Added it directly to my Dockerfile.
Just the CMD for the `go mod download` must be a RUN, otherwise it does not
downlad but prepares that other kind of entrypoint.
> RUN cd cmd/asm
>
> This doesn't doo what you think it does; it does not change the working
> directory. For that, you want the WORKDIR directive. However...
>
> >
> > Why does the go tool try to kind of resolve the import path of my
> project itself? I thought this would be defined by the module directive in
> my go.mod file, at the source root of my project directory?
>
> It is, the Go tool generally uses that to specify where the package
> "lives" if it's working properly. This looks to me almost like it's not
> seeing go.mod correctly.
>
The error is, as stated above and by Tamás, that my `RUN cd .. ` did not
enter the directory with my main.go file.
In fact, the compiler finds my go.mod and go.sum files and starts the
download and then something strange happens. It does not find any *.go
files as there are none in the top level directory and the message I get
with "can't load package .." is the error message for not finding anything
it could compile. I get this error on my local box as well as soon as I try
to `go build` inside the same root directory.
Now, looking back at yesterday, I understand what confused me the most.
Inside my $GOPATH the error message is quite similar but a bit more
distinct:
can't load package: package github.com/Comradin/go-experiments: no Go files
in /Users/marcus/go/src/github.com/Comradin/go-experiments
`no Go files`, but in the module directory this changes to `unknown import
path`
Many thanks, I raised a level of experience and everything builds just fine
now,
Marcus
--
pedo mellon a minno
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
