{"action":"created","issue":{"url":"https://api.github.com/repos/docker/docker/issues/7149","labels_url":"https://api.github.com/repos/docker/docker/issues/7149/labels{/name}","comments_url":"https://api.github.com/repos/docker/docker/issues/7149/comments","events_url":"https://api.github.com/repos/docker/docker/issues/7149/events","html_url":"https://github.com/docker/docker/issues/7149","id":38373486,"number":7149,"title":"Proposal: Dockerfile BUILD instruction","user":{"login":"proppy","id":5268,"avatar_url":"https://avatars.githubusercontent.com/u/5268?v=3","gravatar_id":"","url":"https://api.github.com/users/proppy","html_url":"https://github.com/proppy","followers_url":"https://api.github.com/users/proppy/followers","following_url":"https://api.github.com/users/proppy/following{/other_user}","gists_url":"https://api.github.com/users/proppy/gists{/gist_id}","starred_url":"https://api.github.com/users/proppy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/proppy/subscriptions","organizations_url":"https://api.github.com/users/proppy/orgs","repos_url":"https://api.github.com/users/proppy/repos","events_url":"https://api.github.com/users/proppy/events{/privacy}","received_events_url":"https://api.github.com/users/proppy/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/docker/docker/labels//tools/build","name":"/tools/build","color":"0052cc"},{"url":"https://api.github.com/repos/docker/docker/labels/feature","name":"feature","color":"bfd4f2"},{"url":"https://api.github.com/repos/docker/docker/labels/Proposal","name":"Proposal","color":"009800"},{"url":"https://api.github.com/repos/docker/docker/labels/UX","name":"UX","color":"fbca04"}],"state":"open","locked":false,"assignee":{"login":"tiborvass","id":827131,"avatar_url":"https://avatars.githubusercontent.com/u/827131?v=3","gravatar_id":"","url":"https://api.github.com/users/tiborvass","html_url":"https://github.com/tiborvass","followers_url":"https://api.github.com/users/tiborvass/followers","following_url":"https://api.github.com/users/tiborvass/following{/other_user}","gists_url":"https://api.github.com/users/tiborvass/gists{/gist_id}","starred_url":"https://api.github.com/users/tiborvass/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tiborvass/subscriptions","organizations_url":"https://api.github.com/users/tiborvass/orgs","repos_url":"https://api.github.com/users/tiborvass/repos","events_url":"https://api.github.com/users/tiborvass/events{/privacy}","received_events_url":"https://api.github.com/users/tiborvass/received_events","type":"User","site_admin":false},"milestone":null,"comments":29,"created_at":"2014-07-22T06:50:19Z","updated_at":"2015-02-28T09:39:35Z","closed_at":null,"body":"TLTR; \r\n\r\n`BUILD /rootfs/path/to/context` == `RUN docker build /rootfs/path/to/context`\r\n\r\n-------\r\n\r\nThis was originally a fork of proposal #7115, as I didn't want to pollute the main discussion.\r\n\r\nSuggested changes were:\r\n- in #7115 the first argument to `IN` scopes and populates the rootfs of the inner build, and the context are shared w/ the outer build. With this proposal you explicitly pass a new context to the inner build, and you have to `ADD` or `COPY` file from the context to the image, just like a regular `docker build`.\r\n\r\nSince then @tonistiigi made a simpler PoC in #8021, this proposal was then updated to match the PR.\r\n\r\n-------\r\n\r\n## Proposal \r\n\r\nMost application that build from sources have a disjoint set of build and runtime dependencies/requirements. Because of convenience and in order to benefit from [automated build](https://docs.docker.com/docker-hub/builds/), most images bundle both in their docker images.\r\n\r\nA common example is a go application, where the go toolchain and possibly a C compiler is necessary to build the app, but `busybox` is totally fine to run it.\r\n\r\nAnother example is a java application, where the JDK is necessary to build the app, but the JRE is enough to run it.\r\n\r\nThis proposal derives the main ideas from #7115 and #8021 to introduce a simple syntax for allowing chained build with explicit contexts. The indent is to generalize and consolidate workarounds introduced w/ #5715 (`docker run builder | docker build -t runner`) into the main Dockerfile syntax.\r\n\r\n### New Dockerfile keyword `BUILD`\r\n\r\n#### Usage:\r\n```\r\nBUILD <path/to/context> [path/to/Dockerfile]\r\n[FROM ...\r\nother Dockerfile instructions]...\r\n```\r\n\r\n#### Description:\r\n`BUILD` triggers a new docker build job using a given context directory (coming from the image rootfs being built), followed by new Dockerfiles instructions.\r\n\r\nEither the instructions following the BUILD command, the `path/to/Dockerfile` argument, or the `Dockerfile` at the root of the new `<context>` are used in-lieu-of the new `Dockerfile`.\r\n\r\nThe new build start with a fresh rootfs populated from the inner `FROM` instructions and a fresh environments and replaces the current build job.\r\n\r\nIt is effectively equivalent to being able to call `RUN docker build /path/to/context` in a `Dockerfile`.\r\n\r\n#### Example:\r\n```\r\nFROM ubuntu\r\n\r\nRUN apt-get install build-essentials\r\nADD . /src\r\nRUN cd /src && make\r\n\r\nBUILD /src/build\r\nFROM busybox\r\nCOPY app /usr/local/bin/app\r\nEXPOSE 80\r\nENTRYPOINT /usr/local/bin/app\r\n```\r\n\r\nNote that:\r\n- the context in chained build is different from the context in the previous build.\r\n- `docker build -t` would tag the last chained build defined at the end the Dockerfile until there is a better support for naming distinct image in `Dockerfile` (the problem already exists today with multiple `FROM`)\r\n- changes made to `/src/build` after the `BUILD` block won't be represented in the chained image (but `/src/build` might be reused in another `BUILD` block in the same image).\r\n- chained `BUILD`s can't make change to the previous directory being passed as the context, much like regular build can't mutate the context: the context gets tared like regular `docker build` today and the inner `BUILD` operate on a copy."},"comment":{"url":"https://api.github.com/repos/docker/docker/issues/comments/76519130","html_url":"https://github.com/docker/docker/issues/7149#issuecomment-76519130","issue_url":"https://api.github.com/repos/docker/docker/issues/7149","id":76519130,"user":{"login":"tonistiigi","id":585223,"avatar_url":"https://avatars.githubusercontent.com/u/585223?v=3","gravatar_id":"","url":"https://api.github.com/users/tonistiigi","html_url":"https://github.com/tonistiigi","followers_url":"https://api.github.com/users/tonistiigi/followers","following_url":"https://api.github.com/users/tonistiigi/following{/other_user}","gists_url":"https://api.github.com/users/tonistiigi/gists{/gist_id}","starred_url":"https://api.github.com/users/tonistiigi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tonistiigi/subscriptions","organizations_url":"https://api.github.com/users/tonistiigi/orgs","repos_url":"https://api.github.com/users/tonistiigi/repos","events_url":"https://api.github.com/users/tonistiigi/events{/privacy}","received_events_url":"https://api.github.com/users/tonistiigi/received_events","type":"User","site_admin":false},"created_at":"2015-02-28T09:39:35Z","updated_at":"2015-02-28T09:39:35Z","body":"> changes made to /src/build after the BUILD block won't be represented in the chained image (but /src/build might be reused in another BUILD block in the same image).\r\n\r\nThis one confuses me a bit. You can never go back to the parent build, so there is no way to change anything in `/src/build`. The path to the context loses its meaning after `BUILD` the same way as the daemon doesn't know the path you used for context in the client side. When multiple `BUILD` commands are used the context path points to the directory in the last image.\r\n\r\n`path/to/Dockerfile` is not in #8021 but only because that code predates custom Dockerfiles. We should define that when this path is set and you have more commands after the `BUILD` then this will return a build error. Other way would be to concatenate but I think it just complicates things.\r\n\r\nParent tagging is also different but I'm ok with leaving this out until there is an idea that everybody can agree upon."}}