Skip to content

LCOW: WORKDIR correct handling #34405

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

Merged
merged 1 commit into from
Aug 18, 2017
Merged

Conversation

lowenna
Copy link
Member

@lowenna lowenna commented Aug 4, 2017

Signed-off-by: John Howard jhoward@microsoft.com

WORKDIR in LCOW mode was being treated as a Windows path and not working - /bin was being translated to C:\bin. This fixes it to use Unix semantics.

PS E:\docker\build\lcow> docker build -f workdir --no-cache .
Sending build context to Docker daemon  6.144kB
Step 1/2 : FROM busybox
 ---> efe10ee6727f
Step 2/2 : WORKDIR /bin
 ---> 29731c1d2cbd
Removing intermediate container 7425c28fb858
Successfully built 29731c1d2cbd
PS E:\docker\build\lcow> docker inspect -f "{{.ContainerConfig.Cmd}} -- {{.Config.WorkingDir}}" 297
[/bin/sh -c #(nop) WORKDIR /bin] -- /bin
PS E:\docker\build\lcow> docker run --rm 297 pwd
/bin
PS E:\docker\build\lcow> docker run --rm 297 ls -l ./sh
-rwxr-xr-x  385 root     root       1049592 Aug  4 18:44 ./sh
PS E:\docker\build\lcow>

@johnstep @dnephin PTAL

@gupta-ak - I left a TODO in there for the remote filesystem operation.

@lowenna lowenna force-pushed the jjh/lcowworkdir branch 2 times, most recently from bca1b6f to e2c0405 Compare August 4, 2017 18:58
{"linux", ``, `foo`, `/foo`, ``},
{"linux", ``, `/foo`, `/foo`, ``},
{"linux", `/foo`, `bar`, `/foo/bar`, ``},
{"linux", `/foo`, `/bar`, `/bar`, ``},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since normaliseWorkdirUnix replaces Windows path separators with Unix, how about tests for that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added case {"linux", \a, b\c, /a/b/c, ``},

@lowenna
Copy link
Member Author

lowenna commented Aug 4, 2017

Updated for docker run --workdir to work as well.

PS E:\docker\build\lcow> docker run --rm --workdir /bin busybox ls -l sh
-rwxr-xr-x  385 root     root       1049592 Aug  4 19:56 sh

config.WorkingDir = filepath.FromSlash(config.WorkingDir) // Ensure in platform semantics
if !system.IsAbs(config.WorkingDir) {
wdInvalid := false
if runtime.GOOS == platform {
Copy link
Member

@johnstep johnstep Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a sufficient LCOW check? I think so, at least for now, but maybe system.LCOWSupported is preferred.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could be more explicit, but in reality, here it's redundant. It can only be LCOW.

Copy link
Member

@johnstep johnstep left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tonistiigi
Copy link
Member

tonistiigi commented Aug 9, 2017

As discussed in #33854 there is no such thing as "build platform". Only platform for current stage (and maybe default platform for image access if maintainers can agree on it). So these should be used instead for detecting if conversion is needed. Ideally I would even like if this conversion only happens on starting a container instead of the builder but we can discuss that in another issue. OCI image spec doesn't seem to define anything about C: prefix.

@lowenna
Copy link
Member Author

lowenna commented Aug 9, 2017

As discussed in #33854 there is no such thing as "build platform".

To be more accurate, your goal is that there shouldn't be such a thing as a "build platform". I don't necessarily disagree (entirely), but the fact is it's there presently, and the resolution of how the code base gets updated, if indeed to use FROM --platform is orthogonal to making progress on LCOW in the limited time available to hit RTM. This PR doesn't do anything contentious that isn't already in the codebase.

So these should be used instead for detecting if conversion is needed.

Yes, but after #33854 has been ratified and agreed.

Ideally I would even like if this conversion only happens on starting a container instead of the builder but we can discuss that in another issue.

Sure, that's for later and also orthogonal. But I have concerns about cache breaks if you are going to consider that. The builder has done normalization in this way since WS2016 TP4 days - a very long time. This PR doesn't change that, it just makes sure that the Windows daemon doesn't universally assume it's a full Windows path.

CI image spec doesn't seem to define anything about C: prefix.

Again, if it doesn't, that is also orthogonal to this PR and something which needs addressing in the OCI docs rather than here.

@@ -16,7 +17,7 @@ func TestNormaliseWorkdir(t *testing.T) {
}

for _, test := range testCases {
normalised, err := normaliseWorkdir(test.current, test.requested)
normalised, err := normaliseWorkdir(runtime.GOOS, test.current, test.requested)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: normalize (do we standardize on us eng?)

@@ -5,25 +5,31 @@ package dockerfile
import "testing"

func TestNormaliseWorkdir(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Normalize"

@tonistiigi
Copy link
Member

As discussed offline, both build and create paths will need to be updated based on the #33854 outcome and the current definitely isn't correct. LGTM to unblock

Signed-off-by: John Howard <jhoward@microsoft.com>
@johnstep johnstep merged commit 30eb4d8 into moby:master Aug 18, 2017
@stevvooe
Copy link
Contributor

@johnstep Are we going to have a PR correcting the spelling errors before merging?

@johnstep
Copy link
Member

@stevvooe I also prefer we standardize on language and locale. Is there official guidance for this somewhere? Can it be overridden on a file-by-file basis? @jhowardmsft, what is your take?

@stevvooe
Copy link
Contributor

I took care of it in #34602.

@thaJeztah thaJeztah added the area/lcow Issues and PR's related to the experimental LCOW feature label Oct 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/lcow Issues and PR's related to the experimental LCOW feature status/2-code-review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants