Conversation
|
Please sign your commits following these rules: $ git clone -b "feat-add-exec-build" git@github.com:orisano/compose.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -fAmending updates the existing PR. You DO NOT need to open a new one. |
86b5fa7 to
6c78203
Compare
compose/service.py
Outdated
| line = p.stdout.readline() | ||
| if line == "": | ||
| break | ||
| line = line.replace("writing image sha256:", "Successfully built ") |
There was a problem hiding this comment.
for bypass this.
https://github.com/docker/compose/blob/master/compose/service.py#L1110
for event in all_events:
if 'stream' in event:
match = re.search(r'Successfully built ([0-9a-f]+)', event.get('stream', ''))
if match:
image_id = match.group(1)There was a problem hiding this comment.
This doesn't seem robust.
Can we just append Successfully built... when it didn't appear from docker build CLI?
There was a problem hiding this comment.
I do not know how to get image_id from stdout on docker build --progress=plain.
Do you have any idea?
There was a problem hiding this comment.
I implemented to use an iidfile method.
|
cool! It's not the first time using the CLI is an option (see https://docs.docker.com/compose/reference/envvars/#compose_interactive_no_cli ). maybe there is a way to normalize this? |
|
I'm keen to contribute here - is there any guidance from the compose team as to how they'd prefer this to be implemented? |
|
Not a compose maintainer but this seems ok approach to me. We'll probably take a bit different stab at the same problem at https://github.com/tonistiigi/buildx/issues/13 but the solutions don't seem conflicting and have bit different use cases. |
compose/cli/main.py
Outdated
| parallel_build=options.get('--parallel', False), | ||
| silent=options.get('--quiet', False) | ||
| silent=options.get('--quiet', False), | ||
| _exec=bool(options.get('--exec', False)), |
There was a problem hiding this comment.
Perhaps other locations as well, but I'm not a python coder 😅 and not super-familiar with the codebase (just noticed the PR)
36ed2fa to
19b5db9
Compare
4b6ead0 to
dc13745
Compare
|
A general doubt I have is about the name of the option... |
85a986a to
dc846f7
Compare
|
Please rebase your PR with upstream |
dc846f7 to
69415b1
Compare
|
rebased |
|
ping @ulyssessouza The last request change is already done 🙂 Is there something else missing? |
|
Is there anyway to read |
+1, would be nice to know it looks the same between both
I think the most common part of the output that would be beneficial would be if a layer is cached or not (cache state). One other nice to have (but notpossible via Buildkit? and independent of this PR) would be exposing intermediate layer image SHA/digests. I've had to on occasion grab the SHA/digest before a failure and run |
|
Have we addressed the changes needed to merge this PR? |
|
I'm a little worried this fell into the trap of the perfect being the enemy of the good. This PR offers an opt-in, which will offer a good path for folks who need buildkit and don't need build output. The path forward for using the CLI all the time would be good to determine, but it shouldn't block the simple use-case that this PR supports. |
|
This PR adds a new flag, in addition to all flags that the CLI supports, which means that all of those would have to be supported for future releases |
|
If that’s a problem, then if this is merged and announced and documented as experimental it doesn’t have to be supported. I’m personally running the fork that has the feature and will do so for the foreseeable future. I also pledge do my utmost to help do any possible work required to get this merged. |
Signed-off-by: Nao YONASHIRO <yonashiro@r.recruit.co.jp>
Signed-off-by: Nao YONASHIRO <yonashiro@r.recruit.co.jp>
Signed-off-by: Nao YONASHIRO <yonashiro@r.recruit.co.jp>
Signed-off-by: Nao YONASHIRO <yonashiro@r.recruit.co.jp>
Signed-off-by: Nao YONASHIRO <yonashiro@r.recruit.co.jp>
Signed-off-by: Nao YONASHIRO <yonashiro@r.recruit.co.jp>
Signed-off-by: Nao YONASHIRO <yonashiro@r.recruit.co.jp>
Signed-off-by: Ulysses Souza <ulysses.souza@docker.com>
Signed-off-by: Ulysses Souza <ulysses.souza@docker.com>
Only handles the arguments already supported by `docker-compose build` Signed-off-by: Ulysses Souza <ulysses.souza@docker.com>
89cbe40 to
76e453d
Compare
|
Hello @orisano. I'm sorry for the late response. As you can see, I just pushed 3 commits related to the internal meetings with @thaJeztah and the team.
PTAL @thaJeztah Please note this feature is EXPERIMENTAL and could be removed at any new version |
|
Thanks @ulyssessouza - that looks good for a start! The only thing I'm thinking is if we should add the That could be done as a follow-up though (we'll need follow-ups to discuss / implement other flags anyway) I haven't tried building/testing this PR yet; did you try if setting We'll also need to make sure the Some other thoughts;
|
|
I have taken this through some limited manual testing on a Linux x86 box Would it be fair to argue that this PR should produce similar behavior for
Currently, the first uses buildkit (w DOCKER_BUILDKIT=1, COMPOSE_NATIVE_BUILDER=1), but the second does not, |
Thanks for testing it! Yes, I think it should work for both (but currently doesn't) (see my comment above yours) @ulyssessouza is it difficult to make |
|
orisano@aac7193 |
|
Hello all! Now that the requirements of the PR/issue are quite solid, I just opened a new PR to manage this in a clear way. Once again, thanks a lot for the contribution @orisano ! |
i implemented --exec option on
docker-compose buildfor to use buildkit.This PR is prototype. please give me feedback.