[jb] add a warning if runtime Xmx is different from configured

[akosyakov]

An idea is to detect a user change to the actual max heap size in the backend plugin and suggest a user to put in .gitpod.yml to persist. So the flow would be like:

• a user starts using with default Xmx
• experience perf issues and follow notifications to upgrade Xmx of the running instance
• after JB backend restart there will be a warning on .gitpod.yml that Xmx of the running instance was changed, but it should be applied to .gitpod.yml to be persistent

@yaohui-wyh Maybe you can have a look how we can validate .gitpod.yml? Basically add a warning on .gitpod.yml or on a project if the file is missing if configured Xmx at runtime is different from default one. Later we can add a quick fix to add it into .gitpod.yml

[yaohui-wyh]

Hi Anton! Sure, I would look into it.

[yaohui-wyh]

Some thoughts:

1. Pure JB plugin implementation:

   1. backend-plugin: Check runtime maxHeapSize (-Xmx) when JetBrains IDE startup.
   2. backend-plugin: Extract -Xmx value if .gitpod.yml exists, and show Warning Notifications in case runtime_Xmx != .gitpod.yml_Xmx, when user clicks on "OK" JetBrains IDE opens/creates-if-missing .gitpod.yml automatically.
   3. --- by now the adjusted Xmx configuration can be detected and modified by users manually ---
   4. backend-plugin: Add inspections to .gitpod.yml (e.g. show squiggly underline on mismatched -Xmx=xxx). Add quick-fix intention to modify/add-if-missing the vmoptions field with -Xmx=runtime_Xmx.

2. Move gitpod.yml spec validation & quickfix outside of backend-plugin, e.g. Gitpod CLI / status binary / a standalone IDE agent / ...:

   1. gp cli: Add a sub-command like gp inspect ide, and return runtime maxHeapSize of JetBrains IDE (which can also return current heap usage, etc.)
   2. gp cli: Add sub-commands like gp get <fieldKey>, gp set <fieldKey>, e.g. gp get jetbrains.intellij.vmoptions. And -Xmx values can be extracted and modified.
   3. backend-plugin invoke those commands via GitpodCLIService.

Pros & Cons:

1. Approach 1 is much easier and only 1 component (backend-plugin) is changed. (preferred)
2. Approach 2 allows modifying .gitpod.yml from Gitpod control-plane logic (e..g allows users to modify/inspect/quickfix workspace's JetBrains config from Dashboard / Gateway plugin)

What do you think @akosyakov @loujaybee 🙏

[akosyakov]

I would start with 1 and then we can refactor to 2 if necessary. Do you need pointers about how to get yaml AST, modify and so on?

[yaohui-wyh]

I would start with 1 and then we can refactor to 2 if necessary. Do you need pointers about how to get yaml AST, modify and so on?

Thanks Anton, I had some experience playing around with IntelliJ PSI, I will try first and I will let you know if I need help 🤝

[akosyakov]

there is yaml plugin already, so it should work

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.