Custom container executor - scraping artifacts from inside /data/repo/ - git clone/checkout failure

[tkonieczny]

Describe the bug
It's not possible to scrape artifacts from inside project directory (where repo is cloned) - directory is created and volume is mounted there, so git is not able to clone.
Example: Running a playwright test with custom container executor. Artifacts are (by default) saved to playwright-report in the project directory (/data/repo/test/dashboard-e2e/playwright-report).

It's possible to choose different directory, but it's a common thing to save artifacts in project directory (playwright-report, cypress/videos, etc.).

{"type":"line","content":":package: Fetching test content from git...","time":"2023-04-24T15:21:19.570216473Z"}
{"type":"line","content":"Git parameters: [clone -b main --depth 1 ************************************ repo]","time":"2023-04-24T15:21:19.572674593Z"}
{"type":"line","content":":x: Failed to fetch git: could not start process with command: git, exited with code:128  error: exit status 128\noutput: fatal: destination path 'repo' already exists and is not an empty directory.\n","time":"2023-04-24T15:21:19.572774559Z"}
{"type":"line","content":":x: Could not fetch test content: failed to fetch git: could not start process with command: git, exited with code:128  error: exit status 128\noutput: fatal: destination path 'repo' already exists and is not an empty directory.\n","time":"2023-04-24T15:21:19.572806612Z"}
{"type":"error","content":"could not fetch test content: failed to fetch git: could not start process with command: git, exited with code:128  error: exit status 128\noutput: fatal: destination path 'repo' already exists and is not an empty directory.\n","time":"2023-04-24T15:21:19.57284225Z"}
...
{"type":"line","content":":white_check_mark: Uploading artifacts using MinIO Uploader","time":"2023-04-24T15:21:29.204098431Z"}
{"type":"event","content":"running test [64469e612f10f4c8c3e07b64]","time":"2023-04-24T15:21:29.204471429Z"}
{"type":"line","content":"Scraping directories: [/data/repo/test/dashboard-e2e/playwright-report]","time":"2023-04-24T15:21:29.204500024Z"}
{"level":"info","ts":1682349689.2045083,"caller":"scraper/filesystem_extractor.go:50","msg":"scraping artifacts in directory: /data/repo/test/dashboard-e2e/playwright-report"}
{"type":"result","result":{"status":null},"time":"2023-04-24T15:21:29.223520617Z"}
{"level":"info","ts":1682349689.2234278,"caller":"scraper/filesystem_extractor.go:85","msg":"skipping tarball creation because no files were scraped"}

To Reproduce
Steps to reproduce the behavior:

apiVersion: executor.testkube.io/v1
kind: Executor
metadata:
  name: container-executor-playwright-v1.32.3
  namespace: testkube
spec:
  image: mcr.microsoft.com/playwright:v1.32.3-focal
  command: ["/bin/sh", "-c"]
  args:
  - "npm install && CI=1 npx playwright test; pwd; ls -lah"
  executor_type: container
  types:
  - container-executor-playwright-v1.32.3/test
  features:
  - artifacts

apiVersion: tests.testkube.io/v3
kind: Test
metadata:
  name: dashboard-e2e-tests
  namespace: testkube
  labels:
    core-tests: executors
spec:
  type: container-executor-playwright-v1.32.3/test
  content:
    type: git
    repository:
      type: git
      uri: https://github.com/kubeshop/testkube
      branch: main
      path: test/dashboard-e2e
      workingDir: test/dashboard-e2e
  executionRequest:
    variables:
      BASE_URL:
        name: BASE_URL
        value: http://testkube-dashboard.testkube.svc.cluster.local:8080
        type: basic
      API_URL:
        name: API_URL
        value: testkube-api-server.testkube.svc.cluster.local:8088/v1
        type: basic
    artifactRequest:
      storageClassName: standard
      volumeMountPath: /data/repo/test/dashboard-e2e/playwright-report
      dirs:
        - ./

Expected behavior
It should be possible to scrape artifacts from any directory. The volume should probably be mounted after git clone/checkout.

Version / Cluster
1.11.7

[vsukhin]

It's a k8s architectutre constraint. data volume is an internal for executor pod, scraper can only access shared volume and scraper works as a different pod. And becuase container executor can run any image, the only real sign of prepared reports is executor pod termination

[tkonieczny]

So, if it's the known tech limitation we should include it in the docs.

It should be handled by the user by:

• Mounting to other directory and changing artifacts dir (if possible)
• Or, mounting to other directory, and coping artifacts after actual test is executed.

[tkonieczny]

[tkonieczny]

/artifacts directory can't be used (permissions issue), but repo is checked out to /data/repo, and /data directory is already created with correct permissions. So, I used /data/artifacts.
#3867

Artifacts are scraped correctly:

{"level":"info","ts":1684706076.5411932,"caller":"scraper/filesystem_extractor.go:50","msg":"scraping artifacts in directory: /data/artifacts"}
{"level":"info","ts":1684706076.7562673,"caller":"scraper/filesystem_extractor.go:91","msg":"creating artifacts tarball with 2 files"}
{"level":"info","ts":1684706076.8796954,"caller":"scraper/minio_uploader.go:47","msg":"MinIO loader is uploading file","file":"artifacts.tar.gz","folder":"646a92bccca1ece77ed44b71","size":6500607}
{"type":"result","result":{"status":null},"time":"2023-05-21T21:54:37.057924175Z"}```

[tkonieczny]

But, from the user perspective having to configure artifacts for every test is quite inconvenient:

executionRequest:
    artifactRequest:
      storageClassName: standard
      volumeMountPath: /data/artifacts
      dirs:
        - ./

Can we make it a default config for custom container executors? We already always check out to /data/repo directory, so I think /data/artifacts would also be a good default.

[vsukhin]

close in favor of #3870