external GitRepository running into build error

[Dariusch]

Hello,

I was initially trying to test your CLI in our gitops repository but ran into errors:

flux-local error:  Error building Fluxtomization in '/Users/foo/gitops'  \
path 'manifests/monitoring/monitoring-config': Specified path is not a directory:  \
/Users/foo/gitops/manifests/monitoring/monitoring-config - \
Is a Kustomization pointing to a path that does not exist?

I believe it is because an external GitReoisitory source is unavailable locally.
We have quite a few of those external sources, it would be nice if you could support them at some point.

Here is a minimal example that runs into the error mentioned above.

---
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: flux-source
  namespace: flux-system
spec:
  ref:
    tag: "v2.1.2"
  interval: 120m
  timeout: 60s
  url: https://github.com/fluxcd/flux2.git
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: flux-dashboards
  namespace: flux-system
spec:
  interval: 10m0s
  path: ./manifests/monitoring/monitoring-config
  prune: true
  sourceRef:
    kind: GitRepository
    name: flux-source
  timeout: 10m

Not referencing the files in the Kustomization files will result in successful commands but incomplete diffs.

Thank you

[allenporter]

Thanks for the feature request. yes, right now there is a major simplifying assumption that all Kustomization references only the local repo. There is currently a way to manually map a GitRepository source to a filesystem path with sources which can map flux-source=./path/to/source but it won't automatically check out and clone the repo.

I think some of the challenges here would just be around checking out the repo in a local copy (determining where to store that) while still keeping everything fast.

[allenporter]

Does it work for you to manually check out the repo as part of your CI then refer to it with --sources?

[Dariusch]

The above is just an example. We are working with 10+ external sources in our GitOps repo. A few of them are huge repositories.

I can understand that this might be out of scope, but I guess, I was hoping to see some kind of pull command, based on the GitRepository spec.ignore field.

For CI this might work, but I was mainly looking into local testing

[allenporter]

Lets explore that in more detail, so the idea is:

• Run a command to pull a GitRepository or OCIRepository (plus filtering from the ignore)
• It's kept on disk somewhere?
• Occasionally you run the pull command manually again
• You can run it for all remote repos in a single command?

I think we'd additionally need these configuration options:

• At least one GitRepository or OCIRepository points a the local repo so we'd need to explicitly figure out which one that is vs which ones are remote and should be pulled
• Likely configuration on where to store the local repos since they persist across CLI runs
• That same configuration could be used instead of or as part of --source so you don't have to specify more than once.

Let me know if you have better thoughts here on how this could work. I consider this still in a brainstorming mode to see if this is feasible/worthwhile where all ideas are welcome.

Aside: Last week i tried playing with kustomize localize (example) to pull in individual remote urls within a Kustomization and I was trying to determine if it made sense to include a command like flux-local localize kustomization to help with maintenance, but don't have a solid idea there yet. This proposal could be something like flux-local locallize gitrepo though the functionality is very different, its kinda a similar idea.

[allenporter]

I realize the other thing I didn't mention from #283 is that you can specify --sources=flux-system if you just want to limit flux-local to only a single GitRepository or OCIRepository with the specified name and completely ignore the other remote repositories. I realize I didn't say this explicitly before, so not sure if that is really what you're looking for as far as a workaround besides building out pulling of all remote repos.