Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unknown flag: from #34762

Closed
pbnj opened this issue Sep 7, 2017 · 7 comments
Closed

Unknown flag: from #34762

pbnj opened this issue Sep 7, 2017 · 7 comments

Comments

@pbnj
Copy link

pbnj commented Sep 7, 2017

Description
Multi-stage builds fail with error: Unknown flag: from

Steps to reproduce the issue:

  1. Given this Dockerfile
    • Also tried with FROM golang:1.7.3 as builder and COPY --from=builder (per docs), but I receive a different error: Error parsing reference: "golang:1.7.3 as builder" is not a valid repository/tag
  2. docker build -f Dockerfile -t petermbenjamin/orthrus:latest .

Describe the results you received:

Sending build context to Docker daemon  34.56MB
Step 1 : FROM golang:latest
 ---> 6d9bf2aec386
Step 2 : WORKDIR /go/src/github.com/petermbenjamin/orthrus
 ---> Using cache
 ---> cc19e885c57b
Step 3 : COPY . /go/src/github.com/petermbenjamin/orthrus
 ---> 0887e4e4a22b
Removing intermediate container 102ed65bb320
Step 4 : RUN go get -u github.com/golang/dep/cmd/dep && dep ensure -v
 ---> Running in 94c579faf249
Root project is "github.com/petermbenjamin/orthrus"
 10 transitively valid internal packages
 13 external packages imported from 7 projects
...skip for brevity...
 ---> 1cd44eb03be9
Removing intermediate container 94c579faf249
Step 5 : RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o orthrus cmd/orthrus/main.go
 ---> Running in 48f2c0d31c58
 ---> d7b23d08a670
Removing intermediate container 48f2c0d31c58
Step 6 : FROM alpine:latest
 ---> 7328f6f8b418
Step 7 : WORKDIR /root/
 ---> Running in d771357b54b9
 ---> 639eb0b06700
Removing intermediate container d771357b54b9
Step 8 : COPY --from=0 /go/src/github.com/petermbenjamin/orthrus/orthrus .
Unknown flag: from

Describe the results you expected:
I expected the 2nd build stage to COPY --from=0 (previous stage) the binary to the root of the alpine container and docker build to complete successfully.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client:
 Version:      17.06.2-ce
 API version:  1.23
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 20:12:06 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      1.11.1
 API version:  1.23 (minimum version )
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Wed Apr 27 00:34:20 2016
 OS/Arch:      linux/amd64
 Experimental: false

Also tried against edge: 17.07.0-ce

Output of docker info:

Containers: 23
 Running: 9
 Paused: 0
 Stopped: 14
Images: 8
Server Version: 1.11.1
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
 Log:
Swarm:
 NodeID:
 Is Manager: false
 Node Address:
Init Binary:
containerd version:
runc version:
init version:
Kernel Version: 4.9.13
Operating System: Buildroot 2017.02
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.954GiB
Name: minikube
ID: AAD3:FP32:T6QX:YLYJ:VV3G:LP7P:HKVO:M6GF:HOV3:7BW3:2DX2:LF35
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox
Experimental: false
Insecure Registries:
 10.0.0.0/24
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
macOS Sierra version 10.12.6

@AkihiroSuda
Copy link
Member

Server:
Version: 1.11.1

The server needs to be 17.05 or later.

@pbnj
Copy link
Author

pbnj commented Sep 7, 2017

Thank you for the quick reply.

Perhaps 1 minor follow-up question/suggestion:

  • Would it be helpful to add that piece of information to the multi-stage user guide docs?
    • Currently, the docs say: Multi-stage builds are a new feature in Docker 17.05 which led me to believe that this is the client version.

@AkihiroSuda
Copy link
Member

cc @mstanleyjones

@mdlinville
Copy link
Contributor

I'm not sure why it led you to believe that. The daemon is where the API gets interpreted, so the API needs to support multistage builds. Are you sure this really needs clarification in the docs?

@pbnj
Copy link
Author

pbnj commented Sep 7, 2017

Seems like a common point of confusion for others as well (e.g. https://youtu.be/yuW6BwOS8Eg?t=38m53s)

@pbnj
Copy link
Author

pbnj commented Sep 7, 2017

@mstanleyjones

I'm not sure why it led you to believe that. The daemon is where the API gets interpreted, so the API needs to support multistage builds. Are you sure this really needs clarification in the docs?

I would argue yes, this needs clarification in the docs.

It's not reasonable to expect docker end-users to know that "the daemon is where the API gets interpreted, so the API needs to support multistage builds".

When the first line of docs states:
screen shot 2017-09-07 at 3 10 31 pm
I can see how it is very easy for someone to, at least, be confused about which version that number refers to.

@drcrallen
Copy link

If you find this looking for travis-ci support for multi-stage docker builds, try updating the docker version in your build as per https://docs.travis-ci.com/user/docker/#Installing-a-newer-Docker-version

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants