Uh oh!
There was an error while loading. Please reload this page.
Added support for url build paths - #1372
Conversation
aanand
commented
Apr 29, 2015
Nice. I think that path validation logic belongs in docker-py, though. |
funkyfuture
commented
May 2, 2015
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. |
jonaseck2
commented
May 5, 2015
Looks like you've already implemented url validation. |
a435676 to
7200314Comparejonaseck2
commented
May 5, 2015
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>
aanand
commented
May 5, 2015
@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. |
jonaseck2
commented
May 5, 2015
1.1.0 works like a charm with https://github.com/jonaseck2/freezing-wookie/blob/master/docker-compose.yml. |
jonaseck2
commented
May 5, 2015
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? |
funkyfuture
commented
May 5, 2015
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. |
aanand
commented
May 6, 2015
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? |
jonaseck2
commented
May 7, 2015
Yes, and just leave enough logic to figure out if it's a file path and apply expansion or not |
dnephin
commented
May 31, 2015
LGTM |
aanand
commented
Jun 1, 2015
Could we get a unit test for invalid URLs? |
dnephin
commented
Aug 24, 2015
I believe this overlaps with #1244 which has docs and a test case |
dnephin
commented
Oct 6, 2015
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 |
dnephin
commented
Nov 5, 2015
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. |
jonaseck2
commented
Nov 17, 2015
Please do. I've been trying to get this done for quite some time now and I haven't found the time for it. |
dnephin
commented
Nov 19, 2015
Rebased in #2430 |
Bumps [golang.org/x/net](https://github.com/golang/net) from 0.34.0 to 0.35.0. - [Commits](golang/net@v0.34.0...v0.35.0) --- updated-dependencies: - dependency-name: golang.org/x/net dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
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.