Custom test path dependency broken with multi-config

[briandealwis]

In GoogleContainerTools/container-debug-support#65 I'm trying to reorganize the skaffold debug helper images to use a Skaffold multi-config setup. I have a custom test definition that specifies dependencies using a pattern:

test:
  - image: skaffold-debug-nodejs
    structureTests: [structure-tests-nodejs.yaml]
    custom:
      - command: "cd helper-image; go test ."
        dependencies:
          paths: ["helper-image/*.go", "helper-image/go.*"]

But my build is failing (logs):

Generating tags...
 - skaffold-debug-go -> skaffold-debug-go:be78dcf
 - skaffold-debug-netcore -> skaffold-debug-netcore:be78dcf
 - skaffold-debug-nodejs -> skaffold-debug-nodejs:be78dcf
 - skaffold-debug-python -> skaffold-debug-python:be78dcf
Checking cache...
 - skaffold-debug-go: Error checking cache.
getting hash for artifact "skaffold-debug-go": getting dependencies for "skaffold-debug-go": pattern "/home/travis/build/GoogleContainerTools/container-debug-support/nodejs/helper-image/*.go" did not match any file

The paths field is marked as a skaffold:filepath but the underlying implementation uses list.Files() which causes problems as paths has been made absolute in the multi-config situation:

skaffold/pkg/skaffold/test/custom/custom.go

Line 149 in 60458eb

return list.Files(ct.testWorkingDir, test.Dependencies.Paths, test.Dependencies.Ignore)

but list.Files() assumes that it must prefix the file patterns with the working directory:

skaffold/pkg/skaffold/build/list/list.go

Line 34 in 60458eb

expanded, err := filepath.Glob(filepath.Join(workspace, pattern))

I'm wondering if we should apply to the skaffold:filepath adjustments to all configs rather than just child configs so that we discover these situations earlier.

Steps to reproduce the behavior

1. Clone https://github.com/briandealwis/container-debug-support/tree/modules at commit briandealwis/container-debug-support@91c712b
2. skaffold build

[gsquared94]

This is what had prompted #5472. I don't think your alternative suggestion can catch these kinds of issues.

[gsquared94]

this should be fixed in #5677