Seeing sync errors in attempting to sync *.html files

[aaron-prindle]

I am currently attempting to add file sync support to the application below for it's *.html files (one file - index.html):
https://github.com/GoogleCloudPlatform/golden-path-for-app-delivery

In attempted to modify the app to use both infer and manual file syncing I get some File exists errors during the sync:

• using infer sync via:

# skaffod.yaml file
... # other parts of the file
build:
  artifacts:
  - image: sample-app
    context: ./
    sync:
      infer:
      - '*.html'

I see error:

$ skaffold dev
... # other output
Watching for changes...
Syncing 1 files for sample-app:96f218a6a3a5ae91385aedda1607584bfd4f025b90478242e8dc13bae71b2a15
WARN[0047] Skipping deploy due to sync error:copying files: running [kubectl --context minikube exec sample-app-dev-cdf9f4f8d-7vfbm --namespace default -c sample-app -i -- tar xmf - -C / --no-same-owner]
 - stdout: ""
 - stderr: "tar: Removing leading `/' from member names\ntar: go/src/app/index.html: Cannot open: File exists\ntar: Exiting with failure status due to previous errors\ncommand terminated with exit code 2\n"
 - cause: exit status 2  subtask=-1 task=DevLoop

I attempting to use manual sync as well and saw the same error although with some different paths

# skaffold.yaml
... # other parts of the file
build:
  artifacts:
  - image: sample-app
    context: ./
    sync:
      manual:
        - src: 'index.html'
          dest: /index.html

The error:

Syncing 1 files for sample-app:d72084a3f558bb761d1291b589e3d3a1de41352395bc09e89ef9f5fa0b34e088
WARN[0093] Skipping deploy due to sync error:copying files: running [kubectl --context minikube exec sample-app-dev-86fc868b9-txkzl --namespace default -c sample-app -i -- tar xmf - -C / --no-same-owner]
 - stdout: ""
 - stderr: "tar: Removing leading `/' from member names\ntar: index.html: Cannot mkdir: Permission denied\ntar: index.html/index.html: Cannot open: No such file or directory\ntar: Exiting with failure status due to previous errors\ncommand terminated with exit code 2\n"
 - cause: exit status 2  subtask=-1 task=DevLoop

I also tried removing the file from the Dockerfile (to see of if this was related to the file previously existing in the image) but I saw the same errors

Not sure what I might be doing wrong here, my understanding is that this should work with both sync types infer and manual and not require any additional changes to other files (Dockerfile, etc) but I seem to have this issue in all attempts

[briandealwis]

Odd: your infer setup works for me:

Syncing 1 files for gcr.io/bdealwis-playground/tmp/golden/sample-app:4063f9f-dirty@sha256:0890611400821131cc585f8b232ab2981e8d8c9c511b94fa6b8a8c02a0754e22
INFO[0048] Copying files:map[index.html:[/go/src/app/index.html]]togcr.io/bdealwis-playground/tmp/golden/sample-app:4063f9f-dirty@sha256:0890611400821131cc585f8b232ab2981e8d8c9c511b94fa6b8a8c02a0754e22  subtask=-1 task=DevLoop
DEBU[0048] getting client config for kubeContext: `cloudtop`  subtask=-1 task=DevLoop
DEBU[0048] Running command: [kubectl --context cloudtop exec sample-app-dev-78b85f95fd-zvz8p --namespace default -c sample-app -i -- tar xmf - -C / --no-same-owner]  subtask=-1 task=DevLoop
DEBU[0049] Command output: [], stderr: tar: Removing leading `/' from member names  subtask=-1 task=DevLoop
Watching for changes...

In the manual case, dest should be a directory. And in this case should be /go/src/app (to match the WORKDIR).

[computerquip-work]

I'm having a similar issue where the container's configured user isn't root. The kubectl invocation doesn't specify a user so the default configured user is used. If that user tries to extract into a directory they don't have access to, it will fail like this.

That's my current thought anyways.

[zp4rand0miz31]

I'm having a similar issue where the container's configured user isn't root. The kubectl invocation doesn't specify a user so the default configured user is used. If that user tries to extract into a directory they don't have access to, it will fail like this.

That's my current thought anyways.

I have a similar problem with a container executing as non-root. Changing the Dockerfile by removing the "USER" line in the Dockerfile fixed it (meaning it's now running as root).

Weird no other skaffold user encountered this problem, do everyone run apps as root in containers ???