Support pre-releases and platform-specific extensions on OpenVSX

[rgrunber]

• Closes Add prerelease and platform-specific publishing for Open VSX #2587 (specifically obsoleting it by simplifying the Jenkinsfile)

• Refactor the Jenkinsfile for simplicity

• There should only be 2 calls to vsce/ovsx . One call to publish the generic version, and another to package the platform-specific versions (in a for-loop)

• The logic to publish pre-release versions should be done transparently

• When publishing a pre-release, all package specific vsixs should embed that data at package-time

Signed-off-by: Roland Grunberg rgrunber@redhat.com

CC @CsCherrYY for a review and some questions since I'm changing things slightly.

• There is a line (now deleted here) in the Jenkinsfile that says // for pre-release versions we only package platform specific extensions. The current change will publish a universal vsix on the platform we don't support (same as for a regular release). Is there a reason we avoided doing this in pre-releases ? Is it ok if we do it ? The --pre-release flag just adds itself onto the regular vsce publish/vsce package calls so it becomes easier if they all do the same thing.
• There is a line (I have kept this behaviour for now) in the Jenkins file that says // for pre-release versions, vsixs are not stashed and kept in project folder. Is this still needed ? I've kept it for now so I just ask to see if I can further simplify things.

[CsCherrYY]

Is there a reason we avoided doing this in pre-releases?

Currently, for pre-releases, we do not package a universal vsix, since we can directly use vsce publish --pre-release to publish it, the step vsce package is not required. In another word, vsce steps:

• for platform specific extension, we should package them first, since --target and --packagePath cannot appear at the same time, see https://github.com/microsoft/vscode-vsce/blob/1dcedef92c742f8557eed25ec843d363f95ca594/src/publish.ts#L64-L71, we should use two steps to package and publish:
  • vsce package (--pre-release) --target win32-x64
  • vsce publish --packagePath ${package.path}
• for universal extension
  • vsce publish (--pre-release) --target win32-ia32 win32-arm64 linux-armhf alpine-x64 alpine-arm64

Note: in vsce, if we want to publish a packaged vsix with --pre-release flag, the vsix should be packaged with --pre-release flag as well. See: microsoft/vscode-vsce#666, but if we directly publish without a package, there is no such limitation.

So if we're sure ovsx supports sth like ovsx publish --pre-release directly, we can keep the behavious consitent between ovsx and vsce.

[CsCherrYY]

// for pre-release versions, vsixs are not stashed and kept in project folder. Is this still needed ?

I add this comment just to indicate that IMO the stash step is not necessary. since pre-release versions will not be uploaded to jboss and vsix files will be excluded in .vscodeignore, we can just leave in the folder and continue publish process. So when adding the pre-release steps I didn't use such stash steps to make it clear.

Update: when reviewing, I found you also removed the stash step in the commit, that's the point. :)

[CsCherrYY]

The changes LGTM overall, just a question about stashing step.

[CsCherrYY]

If the stash step is used to upload vsixs to jboss only, I'm considering if we can move this unstash step under

vscode-java/Jenkinsfile

Line 59 in f564e3d

sh "rm -rf ${artifactDir}"

, to keep the function packageExtensions() behaves consistent between release and pre-release: in both of the two cases, we keep all platform specific vsixs in the folder.

[rgrunber]

I'll make the change. I thought maybe there was some reason the stash was happening for normal releases (and not pre-releases). Maybe the publish call would be affected by their presence or something like that. If not, we can definitely move it out.

[CsCherrYY]

I guess so, looks like a convenient way to store/recover all platfrom vsixs, since the generic vsix will be in the same folder at that time.

Anyway, I think it's clear enough now :)