*,cover in excludeFile breaks downward sync in devspace sync

[MaxSchambach]

What happened?
Using devspace sync I was having trouble with downward syncing files, e.g. changes on the pod were not mirrored locally.
Using a test.txt file at the same project level, the upward sync worked fine but changes were not synced downwards.
I've narrowed it down to this wildcard in my .gitignore file: *,cover which is a common pattern for Python coverage files.
I assume that the literal , in combination with the * wildcard resulted in * being ignored for all downward syncs.

The weird thing about this is that the behavior is different from up and down sync, i.e. up sync works fine.

What did you expect to happen instead?
File patterns in excludeFile to be synced in both directions in the same way.

How can we reproduce the bug? (as minimally and precisely as possible)

• create a .gitignore containing only *,cover
• specifying excludeFile: .gitignore in `devspace.yaml``
• using devspace sync <...> to sync to a remote pod
• creating a dummy file, e.g. echo "test" > test.txt locally. File syncs correctly to remote machine.
• removing or changing the file on the remote machine is not reflected locally.

My devspace.yaml:

version: v2beta1
dev:
  sync-0:
    labelSelector:
      devspaceSync: 'true'
    sync:
      excludeFile: .gitignore
      onUpload: {}
      path: .:/workspace
      printLogs: true

Local Environment:

• DevSpace Version: 6.3.11 (but also confirmed for 6.3.10)
• Operating System: mac (but also confirmed on Linux)
• ARCH of the OS: ARM64 (but also confirmed on AMD64)
  Kubernetes Cluster:
• Cloud Provider: google
• Kubernetes Version: Client Version: v1.27.9-dispatcher
  Kustomize Version: v5.0.1
  Server Version: v1.27.8-gke.1067004

Anything else we need to know?

[lizardruss]

@MaxSchambach

I was trying to figure out what that pattern is supposed to match.. but it appears it may have been a typo that made its way into the wild. That assumption is according to this PR, but if there's an explanation of what that pattern means, we can look into it more.

[MaxSchambach]

The pattern is meant in a literal way, in particular matching <filename.py>,cover (as included also in the default GitHub repo which was brought back in this commit).

I agree, it looks very unusual, but is, unfortunately, the naming convention that coverage.py uses to report per-file coverage, see also this StackExchange thread. It mentions the PR you also linked, but the discussion of that PR also mentions that this is indeed not a typo, see here.

[lizardruss]

Ah, thank you. Helps if I read the whole thread. This will take some additional debugging, since these patterns are matched by a 3rd party library, and its not clear if this issue lies there or in DevSpace. We'll update when we know more 👍

[MaxSchambach]

Any update on this?