Jakub Chrzanowski

``` > [email protected] postinstall /opt/bitnami/apps/jenkins/jenkins_home/jobs/Project/workspace/node_modules/mozjpeg > node lib/install.js ⚠ The `/opt/bitnami/apps/jenkins/jenkins_home/jobs/Project/workspace/node_modules/mozjpeg/vendor/cjpeg` binary doesn't seem to work correctly ⚠ mozjpeg pre-build test failed ℹ compiling from source ✖ Error: autoreconf -fiv...

Those are valid points — passing the `runtimeDirectory` to Plugin Verifier makes it use the JBR bundled with the IntelliJ Platform you use for building the plugin, not the one...

This is not planned to be addressed in 1.x; For 2.0, it is now possible to configure those URLs as described here: https://github.com/JetBrains/intellij-platform-gradle-plugin/issues/1686#issuecomment-2221297523

I tis now fixed with [IJPL-158473](https://youtrack.jetbrains.com/issue/IJPL-158473) and will be released in IntelliJ IDEA 2024.1.5 and 2024.2.

Thanks for highlighting that. In the latest `beta9`, I've adjusted loading the local plugin — it is now consuming the output ZIP archive — in the same way it works...

Hi, @shyim! Sure, any upcoming GitHub Qodana Plugin releases will be handled appropriately with GitHub Releases, tags, etc.

What is the reason for that? Versioned directories within the sandbox container directory enable introducing custom tasks, like running a custom IDE with the plugin loaded with a different IntelliJ...

What about ```kotlin tasks { prepareSandbox { sandboxDirectory = intellijPlatform.sandboxContainer.dir("fixedName") } } ```

Thank you for highlighting the above issue! Apparently, tasks didn't inherit from the sandbox producer (`prepareSandbox`), but that is now fixed. It'll be available this week with `2.0.0-beta4`. BTW, if...

The sandbox management was revisited again in `beta8`. With the current `beta9`, it works as described above.