Docker-Compose: Composing with Dockerfiles that need relative imports

To begin, this is my project hierarchy:

myproj/
    - commons1/
        - com1_file1.go
        - ...
    - commons2/
        - com2_file1.go
        - ...
    - module1/
        - mod1_file1.go
        - Dockerfile
        - ...
    - module2/
        - mod2_file1.go
        - Dockerfile
        - ...
    - docker-compose.yml

What I'd like to do is that when module1 and module2 containers start up, they each have a copy of all the commonsN directories in their GOPATH's so that each can access the common libraries exposed by each of the commonsN directories.

For example, I would like to see something like this in the container for module1:

/go/
    - src/
        - commons1/
            - com1_file1.go
            - ...
        - commons2/
            - com2_file1.go
            - ...
        - module1/
            - mod1_file1.go
            - ...

Reason being is that this is basically how my local GOPATH looks (with the addition of the other modules of course) so that I can do something like this in my source files:

package main

import(
    "fmt"
    "myproj/commons1"
)

func main() {
    fmt.Println("Some thing from common library :", commons1.SomethingFromCommons)
}

From my naive understanding of Docker, it appears I'm not allowed to modify my Dockerfiles to do something along the lines of COPY ../commons1 /go/src/commons1, so I'm wondering how I would go about accomplishing this?

I would strongly prefer to not go the Github route since the source code is all behind company proxies and whatnot and I'm imagining configuring all that is going to take way longer than simply copying some directories.

Edit
I have updated my docker-compose.yml file to look something like this per suggestion from barat:

version: '2'

services:
    module1:
        volumes:
            - ./commons1:/go/src/myproj/commons1
        build: module1/

Dockerfile for module1 looks like this:

FROM golang:1.8.0

RUN mkdir -p /go/src/app
WORKDIR /go/src/app

COPY . /go/src/app
RUN go get -d -v
RUN go install -v

ENTRYPOINT /go/bin/app

EXPOSE 8080

docker-compose build fails on the go get -d -v with error:

>package myproj/commons1: unrecognized import path "myproj/commons1" (import path does not begin with hostname)

If myproj/commons1 was copied into /go/src/, then this shouldn't be an issue right? I'm guessing then it hasn't been copied over then?

You could build an image including commons1 and commons2 that your other images are based on.

FROM golang:1.8.0
RUN mkdir -p /go/src/myproj/commons1 && mkdir -p /go/src/myproj/commons2
COPY commons1/ /go/src/myproj/commons1/
COPY commons2/ /go/src/myproj/commons2/

The downside is this requires an external build step whenever you update one of the common projects:

docker build -t me/myproj:commons .

Then your compose apps can rely on the commons image instead of golang and build as normal without the volumes.

FROM me/myproj:commons
...

So problem was the go get -d -v command since it was complaining myproj/commons1 wasn't installed in $GOPATH/src basically. This I of course suspect was because Docker Compose wasn't mounting the volumes I mentioned before it ran the go get on docker-compose build so I made a work around in my docker-compose.yml but it is far from elegant:

version: '2'

services:
    module1:
        volumes:
            - ./commons1:/go/src/myproj/commons1
        build: module1/
        ports:
            - "8080:8080"
        command: bash -c "go get -d -v && go install -v && /go/bin/app

This is obviously far from ideal because my Go binary is rebuilt every time I do a docker-compose up regardless of whether or not I ran docker-compose build.

This is also problematic because I wanted to use dockerize for certain containers to wait until another container has started up completely and it becomes quite messy now I think.