You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When developing plugins, I always try to use the JetBrains Runtime SDK. But the Zulu SDK is used on CI, hence the question: "Is it worth bothering and using the JetBrains Runtime SDK on CI?"
Proposed solution
If so, it is worth adding JetBrains Runtime support to actions/setup-java.
I've already looked into whether this is possible: Yes, but with complications (but that's another issue).
Alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
That's a valid question, Danil — thanks for asking.
I plan to send a PR to actions/setup-java to make them aware of JBR, but this has a low-priority ATM.
Also, a bundled JBR should be considered a first option rather than a JBR resolved with the Gradle.
Given both, I reverted that setup so as not to ask Gradle for JBR now.
With the IntelliJ Platform Gradle Plugin 2.0, that resolving mechanism will be corrected + I will try to craft a proper change to the GitHub Action.
Note: the IntelliJ Platform Gradle Plugin 2.x changed the approach and is using now IDE Installers as a target IntelliJ Platform in the first place, which have JBR bundled.
Describe the need of your request
It's more of a question than a suggestion :)
When developing plugins, I always try to use the
JetBrains Runtime
SDK. But theZulu
SDK is used on CI, hence the question: "Is it worth bothering and using theJetBrains Runtime
SDK onCI
?"Proposed solution
If so, it is worth adding
JetBrains Runtime
support toactions/setup-java
.I've already looked into whether this is possible: Yes, but with complications (but that's another issue).
Alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: