Add prerelease and platform-specific publishing for Open VSX

[filiptronicek]

Hi there, an Open VSX commiter here 👋!

Context

Open VSX has today deployed a change adding the ability to do both pre-releases and platform-specific extensions the same way the Microsoft (VS Code) Marketplace handles them.

This PR adds publishing of both of these to the Jenkins file. Mainly the platform-specific releases will help a bunch with their integrated JREs in some environments.

P.S.: I have never written Jenkins jobs before so this may need a small review.

[rgrunber]

I noticed a little while ago that ovsx got these options around March, so have been wanting to investigate this. @fbricon, you mentioned some concerns as to whether the pre-release stream is properly separated from regular releases on OpenVSX ? Maybe @filiptronicek can elaborate on it.

I guess we need to play with it in VS Codium to confirm. If it all looks good, I'll merge this proposal.

As a note, we add the pre-release option in the vsce package invocation for the platform specific vsix that we support. For the ones we don't support (generic version), we add the pre-release option for the vsce publish. I think this PR is missing that currently, but it can be added. The reason for this confusing workflow is due to some limitations in the package/publishing.

[filiptronicek]

Hi @rgrunber!

We did indeed add these features back in March, but the deployment pipeline has been causing some real big issues there. We actually deployed when I raised this PR, but since then had to revert and go back because the entirety of https://open-vsx.org went down 😕.

the pre-release stream is properly separated from regular releases on OpenVSX

Do you mean "seperated" as in the UI of Open VSX, the backend or inside VS Code? Inside VS Code, pre-release versions are only a part of the pre-release channel the same way as the Microsoft Marketplace. In the UI, all versions are included in the extensions's UI (stable & pre-release), but they are clearly marked and users can always easily switch to the latest stable version if they are viewing a pre-release.

I guess we need to play with it in VS Codium to confirm. If it all looks good, I'll merge this proposal.

I will test the latest version in Gitpod and can do testing in VS Codium too, I will do that hopefuly soon 🤞.

As for the remainder of your comments, I will take a look 🙂. Edit: hopefully addressed this in 3f8b8d6 (#2587).

[rgrunber]

Ok, so I finally tried out VSCodium. Here's what I saw in side-by-side comparison.

In VSCode, I wasn't able to install Jbang using the standard install button as it only has contributed pre-releases. There's a separate context menu from the install button that allows one to switch to installing pre-releases. In VSCodium the install proceeded without issue, and you can see there is no indication that what I installed was a pre-release.

I can confirm the .vsixmanifest of the installed extension does have : <Property Id="Microsoft.VisualStudio.Code.PreRelease" Value="true" />

Another oddity I noticed :

$ diff -u ~/.vscode/extensions/jbangdev.jbang-vscode-0.1.2022083013/package.json ~/.vscode-oss/extensions/jbangdev.jbang-vscode-0.1.2022083013/package.json 
--- /home/rgrunber/.vscode/extensions/jbangdev.jbang-vscode-0.1.2022083013/package.json	2022-08-30 13:57:46.468862902 -0400
+++ /home/rgrunber/.vscode-oss/extensions/jbangdev.jbang-vscode-0.1.2022083013/package.json	2022-08-31 16:05:58.302289497 -0400
@@ -120,14 +120,14 @@
 		"vscode-languageclient": "^8.0.1"
 	},
 	"__metadata": {
-		"id": "...",
-		"publisherId": "...",
-		"publisherDisplayName": "JBang",
+		"id": "...",
+		"publisherId": "...",
+		"publisherDisplayName": null,
 		"targetPlatform": "undefined",
 		"isApplicationScoped": false,
-		"updated": true,
-		"isPreReleaseVersion": true,
-		"preRelease": true,
-		"installedTimestamp": 1661882266468
+		"updated": false,
+		"isPreReleaseVersion": false,
+		"preRelease": false,
+		"installedTimestamp": 1661976358301
 	}
 }
\ No newline at end of file

I didn't find these values in the vsix itself, so I suspect they might come from the marketplace server. I think if there was some indication or action users had to take to make it clear they are now using a pre-release, it would be good. @fbricon , thoughts ?

[rgrunber]

For some context, pre-releases can contain pre-released versions of tooling/features, and it isn't ideal to mark them as a regular releases, prior to upstream officially announcing them. I think this needs to be resolved in ovsx/OpenVSX before we can adopt this.

Maybe we could look at the platform-specific aspect of this change though.

[amvanbaren]

@rgrunber Open VSX now supports pre-releases and target platforms. When you publish a new version of JBang, is it now marked as a pre-release?

[fbricon]

@amvanbaren indeed it works. VS Codium now proposes to switch to the Pre-Release version of JBang.

[filiptronicek]

@rgrunber just a quick FYI: platform-specific extensions should be good to go now, we deployed https://open-vsx.org recently so this PR is no longer blocked 🎉.

[rgrunber]

I'm going to be testing out a change that simplifies the Jenkinsfile, and hopefully is able to also perform package-specific+pre-releases on Open VSX. My motivation is basically that the current state of the Jenkinsfile is really difficult to read and comprehend. We have a lot of odd states that were kept a certain way in part because of the different vsix requirements between VS Code Marketplace & Open VSX. With both supporting the pre-release/package-specific vsixs we should try to make the build file simpler.

[rgrunber]

Just published a package-specific pre-release to https://open-vsx.org/extension/redhat/java . More info can be seen at https://open-vsx.org/api/redhat/java/1.13.2022102814 . On {darwin,linux}-{arm,x}64, and win32-x64 we embed a JRE, and for other platforms, just a universal vsix.

I'll create a new PR once it looks like this is correct, though I don't see anything off about the packages/metadata. I may also ask @CsCherrYY to review as he published some of the original work in the Jenkinsfile to do this (back when the different requirements between registries required workarounds).