-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Couldn't find helm repository? #225
Comments
It looks like it is having a problem finding the
|
This is showing each of these objects above as a separate cluster. For some reason it can't make the linkage between |
Very interesting - so I should be able to play with it locally as well? Will tinker a bit this week |
@szinn Yeah you can, its all based on a command line tool in this repo. You can set Which Fluxtomization is supposed to include the Kustomization |
./kubernetes/cluster/config/cluster.yaml pulls in ./kubernetes/cluster/apps.yaml which loads ./kubernetes/apps which is processed by directory traversal rather than an explicit kustomization. |
OK thanks for confirming that. I suspected that was the case, but wanted to be sure. As its walking through the paths it seems to have trouble with lidar's directory structure:
I'm taking a closer look. I think it may be getting confused because of the explicit |
I think this is getting confused because there are two types of kustomizations in a single directory. A The tool assumes that the directory structure has meaning with respect to representing dependencies. Yikes. |
Ah, with my layout (and others that follow / riff on onedr0p's) the directory structure has meaning but not necessarily for dependencies. ./kubernetes/cluster/config/cluster.yaml is the root entity and it brings in other fluxtomizations and kustomization entities and those alternate back and forth. For the directory you mention with both types, the parent directory will bring in the install.yaml fluxtomization and that will bring in the kustomization in the same directory which loads the app. |
Yes, though I haven't seen this in onedr0p's repo fwiw:
|
I think it works in his repo because he uses a separate |
I think Devin has it in apps/monitoring/vector |
How do I run flux-local from a clone of the repo? |
Ah yes, I see what he has - I didn't think the extra sub-directory to hold the two packages was necessary :-) Same pattern for lidarr |
I have a test repo where i have been able to reproduce this and can see if its straight forward to fix: |
(venv) bash-3.2$ ~/Development/public-repos/flux-local/script/run-in-env.sh flux-local get cluster --path ./kubernetes/cluster/config Looks like it worked |
Great, this has been released in 1.3.1 Thanks for the report 👍🏼 and let me know if anything else acts up. |
Sorry to revisit an old issue, but I'm having a similar issue with my PR flux diff checks.
I've run your local debugging testing and see results that I believe look correct
The FWIW, I pulled the latest What is maybe interesting is that I get a missing HelmRepository that seems to relate to the changing package in the PR. In another one of my PRs it was a missing redis HelmRepository Any ideas? |
Would you be up for filing a new separate issue and we can continue discussing there? One thought I have is that the root cause is #483 but we can dig in more and see. One thing we could do is have you enable |
Sure thing! I'll go ahead and add the debug flag now and trigger the build again. |
https://github.com/szinn/k8s-homelab/actions/runs/5206160235/jobs/9392423235
It seemed to generate a diff but showed the error in the PR - szinn/k8s-homelab#1905
The helm repository is an OCI repository - could that be it?
The text was updated successfully, but these errors were encountered: