Add CLI flag to ignore hidden directories and/or support .gitignore

[ahgraber]

I have "work in progress" .wip/ directories in my local repo that are included in my .gitignore. As these are work in progress, they may be in a state that cause flux-local to crash.

It would be really useful to be able to set flux-local (and the gh Action) to ignore directories that:

• in the .gitignore
• match a glob/regex pattern

[allenporter]

@ahgraber You can can specify --path to point to a specific subdirectory that contains your cluster repo e.g. --path=kubernetes/ or --path=clusters/prod etc

[allenporter]

@ahgraber i believe using --path addresses your issue. Is that right?

[ahgraber]

Mostly! If I want to do a full build of the entire repo (locally), then having a way to exclude multiple patterns would be really useful. However, I probably don't need to do that locally, in which case --path solves the issue, and it's a non-issue in GHA b/c I don't commit the directories.

Thanks for following up! I'll close this.

[jkoelker]

I believe this would be useful. For example my cluster is not in a subfolder, and the tool picks up .github/workflows yaml:

$ flux-local --log-level INFO diff kustomization --unified 6 --strip-attrs "helm.sh/chart,checksum/config,app.kubernetes.io/version,chart" --skip-crds --skip-secrets --limit-bytes 10000 --all-namespaces --kustomize-build-flags="" --sources "" --output-file diff.patch ${extra_flags}
flux-local error:  Command 'flux build ks flux-system --dry-run --kustomization-file /dev/stdin --path /home/jkoelker/jkoelker/nas00 --namespace flux-system' failed with return code 1
✗ failed to generate kustomization.yaml: failed to decode Kubernetes YAML from /home/jkoelker/jkoelker/nas00/.github/workflows/flux-diff.yaml: missing Resource metadata <nil> <nil>

I think having a --ignore-paths that just passes through to flux build would work as I think that's what's picking it up, but i'm not really sure.

[allenporter]

I found out there is a .krmignore file that supports directory names. This is respected by kustomize

[jkoelker]

I found out there is a .krmignore file that supports directory names. This is respected by kustomize

Unfortunately it does not alleviate the issue:

$ cat .krmignore 
.github

$ flux-local       --log-level INFO       diff       kustomization       --unified 6          --strip-attrs "helm.sh/chart,checksum/config,app.kubernetes.io/version,chart"       --skip-crds       --skip-secrets       --limit-bytes 10000       --all-namespaces       --kustomize-build-flags=""       --sources ""       --output-file diff.patch 
flux-local error:  Command 'flux build ks flux-system --dry-run --kustomization-file /dev/stdin --path /home/jkoelker/jkoelker/nas00 --namespace flux-system' failed with return code 1
✗ failed to generate kustomization.yaml: failed to decode Kubernetes YAML from /home/jkoelker/jkoelker/nas00/.github/workflows/flux-diff.yaml: missing Resource metadata <nil> <nil>

[allenporter]

@jkoelker I see -- in this case it looks like its flux build not kustomize which is failing. It seems like the problem is these files are actually included by a kustomization though here right?

I don't think flux-local can have another way to tell flux build to ignore files within the kustomization. How is the kustomize controller ignoring these?

I think i'd need to see more about the details of the repo to figure out a path forward for you.

[jkoelker]

I think the deal is by default the flux controller never sees them as they are excluded from the Artifact by the source controller

The repository was created with flux bootstrap just without specifying a path, so it defaulted to the current directory which is the root of the git repo. flux build supports --ignore-paths which I think would be the right way to pass through flux-local to the build any directories to ignore.

[allenporter]

T

[allenporter]

Thanks for that detail. Yeah, --ignore-paths from the source ref ignores automatically seems interesting/useful if possible.

[allenporter]

One thing that may be hard to automatically do is that we may not have a way to identify the right GitRepository that points to "this cluster" though maybe --sources can pick it up.