Unnecessary config version change can happen when excluded files' contents are modified

[vvagaytsev]

Bug

Container modules get rebuilt when the exclude files are modified.

From the docs:

Files that match these paths or globs are excluded when computing the version of the module, when responding to filesystem watch events, and when staging builds.

However, making changes in the excluded files' contents can cause some unnecessary action/module version changes. In that case, the module is rebuilt when it should not be. But the built images have the same digest, therefore no new images are pushed to the registry, instead, the already existing image in the registry is tagged with yet another version.

Issue

If a file's content from the excluded: list has been modified, it causes the module version change, despite it should be ignored. Here the excluded: config entry is not modified.

This happens only with GARDEN_GIT_SCAN_MODE=subtree.

Current Behavior

An excluded file is not excluded by the Git repo scanner.
Thus, the changes made in the excluded file's content cause the change of module version and, hence, trigger a new build job.

Expected Behavior

An excluded file should not be returned from the Git repo scan.
So, the changes made in the excluded files should not affect the module version.

Reproducible example

kind: Project
name: repro
environments:
  - name: local
  - name: remote
    defaultNamespace: ${var.userId}
providers:
  - name: local-kubernetes
    environments: [local]
variables:
  userId: ${local.username}

---
kind: Module
type: container
name: name
image: name-image
exclude:
  - ./dir1
  - ./file1

1. Run garden build
2. Change any file in the excluded ./dir1
3. Run garden build again

Suggested solution(s)

Fix the GitHandler.getFiles() method to properly exclude all files and directories listed in the exclude: config entry.

Workaround

Not found.

Your environment

This is an environment-agnostic issue. It comes from the Core framework and version calculation logic.

garden version 0.13.18

See also #5519.

[dadadom]

This also seems to affect the jib-container action. Which is especially annoying because our (relatively slow) Kotlin Gradle build is now executed again for a production deployment although there are no changes (except for one excluded changelog file) compared to the latest staging build.

[vvagaytsev]

Thanks @dadadom. Yes, it affects all types of Build actions. The bug comes from the GitHandler class and happens only for GARDEN_GIT_SCAN_MODE="subtree".

The default values of the GARDEN_GIT_SCAN_MODE was changed to "repo" in #5399. That change was released in 0.13.20. So, since 0.13.20 this issue is no longer reproducible until the GARDEN_GIT_SCAN_MODE="subtree" is set explicitly.

I'm working on the fix for the subtree scanning mode.

[dadadom]

Thank you, this is great to hear! We will tackle an upgrade to 0.13.20 hopefully soon, I will try to remember looking for this specific issue!