Fix "Show configuration" command

[WitoDelnat]

Reproduction:

• I used this repository: https://github.com/witodelnat/monokle-example
• I created a policy in the cloud only with rule latest image
• I use "Monokle: Login" command and authenticate
• I use "Monokle: Show configuration" to check if it fetches right policy
• 💥

Remarks

• I'm running on MacOs Ventura with extension v0.4.1.
• Pressing "Open Folder" opens /
• It's unclear to me where we store this / which path it's actually trying to open. I looked under ~/.config/monokle (does not exist) and ~/Library/Preferences/monokle (contains no policies). edit: I found them under ~/Library/Caches/monokle!

[f1ames]

AFAIU the steps, you didn't add repo to any project in Monokle Cloud, right? This way I'm able to reproduce this issue, getting the same result (/ as config path).

Now, it breaks because when user is logged in it expects remote config. Ofc, the case when extension is not able to fetch one (when running show config) is not handled correctly.

I think this is a bigger question, the same we had in CLI - https://github.com/kubeshop/monokle-cli/issues/16. At this stage, Monokle extension, when user is logged in, expects remote config. When it is not able to fetch it, you will see related error message after hovering over statusbar item:

And validation is not run (due to missing config).

There are two ways:

1. Leave it as is, with better error handling for commands which expects config (like show config).
2. Rework config precedence, similar way as in CLI (https://github.com/kubeshop/monokle-cli/issues/16) - so if there is no remote config, local/default one will be used.

The best approach could be combination of both. If there is no project with such repo, fallback to local config. If there is a project with such repo, but still extension is not able to fetch config (e.g. because policy was not defined), just show an error as now - because in this case user intention was most likely to use remote policy.

WDYT @WitoDelnat @olensmar?

[WitoDelnat]

I thought I added it, but it's very likely I actually was doing the scenario like you described. Personally I'm pro rework config precedence. It's unreasonable to expect all repositories to have a remote config and i'd still be nice to use Monokle in that case. You can view configuration to check what you are actually running (which I think is why I ran it - to debug if I was actually using a remote policy). Maybe view configuration with local fallback should add a link promoting Monokle Cloud's remote policy / easy to click on when you notice its wrong?

ps: silly question but the automatic inference takes both repository owner and name into consideration right? Iirc I renamed monokle-demo to monokle-example just to avoid naming conflicts out of precaution.

[f1ames]

ps: silly question but the automatic inference takes both repository owner and name into consideration right? Iirc I renamed monokle-demo to monokle-example just to avoid naming conflicts out of precaution.

Yes 👍 Also git provider (so, in theory, you can have same owner/name from different git providers), but... now I started to wonder how it will behave with 3rd-party git repos 🤔 It will be good to tests with enterprise build since some adjustments (most likely in core) may be needed there 🤔

[f1ames]

Maybe view configuration with local fallback should add a link promoting Monokle Cloud's remote policy / easy to click on when you notice its wrong?

I'll add it. Here, also the more generic approach to guide users through policy creation could be very helpful, we have an issue for that already - https://github.com/kubeshop/vscode-monokle/issues/27. Not for now, but maybe we can reconsider it for near future.