-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Added support for url build paths #1372
Conversation
Nice. I think that path validation logic belongs in docker-py, though. |
i'm afraid it belongs to the config-validation. in #1355 the validation-strategy is to accept nothing that is not defined as being allowed. |
Looks like you've already implemented url validation. |
a435676
to
7200314
Compare
Would this fix be a candidate for a 1.2.1 release? I'm unable to use 1.2.0 due to the broken url support. |
Signed-off-by: Jonas Eckerström <jonaseck@gmail.com>
@funkyfuture Nonetheless, it's not specific to Compose, and should at least be a utility function under @jonaseck2 Is it a regression? I don't think Compose ever supported build URLs. |
1.1.0 works like a charm with https://github.com/jonaseck2/freezing-wookie/blob/master/docker-compose.yml. |
Before 1.2.0 I'm assuming that compose just transparently forwarded the build path to docker and let docker validate the build path. In that sense, adding validation of the build path only limits what docker compose allows itself to pass to docker. I think it's a better idea to separate concerns between docker and compose and leave validation of argument values to docker. Initially, my solution to the issue was to check if the build path was a file path by testing if the relative path didn't exist and the expanded path did, otherwise just send it to docker as is. Perhaps this is a better solution after all, both specifically and for compose in general? |
i didn't meant to deny that. but that it's crucial to do a rehearsal of a composition before the the band goes to stage. i'm kind of traumatized by the expierence of data-loss due to a misconfiguration. so, my remark was like a loud thinking to remind me. in the meantime i added an url-validation to the buildpath-check in #1355. |
Some validation is going to have to happen client-side, because the client needs to know whether to create a tarball or not. But docker-py is already doing that. What if we just remove the build path validation code? |
Yes, and just leave enough logic to figure out if it's a file path and apply expansion or not |
LGTM |
Could we get a unit test for invalid URLs? |
I believe this overlaps with #1244 which has docs and a test case |
An integration test and some docs (which could reference https://docs.docker.com/reference/commandline/build/) would be great. Will need a rebase as well to update with master |
I'd like to get this into the 1.5.1 release. If you don't have any time to update it, let me know, and I will rebase it and add an integration test. |
Please do. I've been trying to get this done for quite some time now and I haven't found the time for it. |
Rebased in #2430 |
Implements #1369
Fixes #491
Shamelessly stole url validation logic from docker.
Manual testing works fine but I've been unable to run the unit tests due to a 404 error from docker when running script/test.