Support platform-specific targets about semantic-release-vsce

[felipecrs]

Answering the PR title: definitely. I don't see why not.

Except for microsoft/vscode#23251 (comment). I'm not sure if it was already solved, because if not, I don't know yet how it would work with semantic-release.

[felipecrs]

Just to update, I would prefer to start working on this after microsoft/vsmarketplace#219 gets solved.

[mbehr1]

is there any kind of workaround to release platform-specific targets yet?

[felipecrs]

None that I know yet, but I will try to take a better look at this later today.

[felipecrs]

I think that a possible workaround is to leave the normal configuration of semantic-release-vsce to publish the generic platform, and use the semantic-release GitHub Action to run subsequent steps (like building and publishing multiple platform targets using vsce directly).

Here is how to use the GitHub Action and how to run subsequent steps if a release is cut:

https://github.com/codfish/semantic-release-action#:~:text=Example%3A%20Only%20run%20an%20action%20if%20a%20new%20version%20was%20created.

Here is an example on how to build and publish for multiple platforms:

https://github.com/microsoft/vscode-platform-specific-sample

I'm thinking about implementing it in vscode-shellcheck.

[felipecrs]

@GitMensch @mbehr1 out of curiosity, in your use-cases, do you actually need to build the extension in the target architecture, or it's only about downloading the correct binaries to package inside of it?

[GitMensch]

I guess both cases are relevant.

[felipecrs]

But there isn't much the semantic-release-vsce plugin can do if the build itself needs to happen in a machine different than the one which the plugin is running.

[GitMensch]

I agree that this would only work if the file is downloaded as part of the CI that triggers the actual build in a docker container/via ssh/... before.

[mbehr1]

@felipecrs see my use case here: https://github.com/mbehr1/dlt-logs/blob/8da25076e906ade96d01d7765badef8b0a2fe08d/.github/workflows/release.yml#L43 I need to build the binaries as well (even though the build job can be done on one machine). I removed/disabled the -vsce plugin for now but still use semantic-release to determine the next version (as I need the new version as build input). For now I trigger a 2nd workflow after the semantic-release (which is a bit poor as e.g. failures would be detected too late)...

[felipecrs]

even though the build job can be done on one machine

Can even the Windows and MacOS ones be done in Ubuntu?

---

I'm thinking about adding some kind of matrix support in the plugin itself, something like:

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    ["semantic-release-vsce", {
        "archs": ["amd64", "aarch64"]
        "packageVsix": true
    }],
    ["@semantic-release/github", {
      "assets": [
        {
          "path": "*.vsix",
          "label": "Extension File"
        },
      ]
    }],
  ]
}

Which would cause the plugin to call vsce package multiple times for each architecture (and set an environment variable with the architecture). Then, you could set up a script that would perform the needed preparations (based on the environment variables set earlier), hooked to the vscode:prepublish command that vsce already is set to execute.

---

Any feedback or ideas are appreciated.

[GitMensch]

Can the Windows and MacOS ones be done in Ubuntu?

Depends on the plugin and architecture, but the Win32 can "in general" be compiled and provided directly, using cross compilation like MinGW.

[felipecrs]

I'm thinking about the following:

1. Document a GitHub workflow where we would run semantic-release --dry-run, with the purpose of determining whether a release shall be cut and what should be the next version.
2. Document a GitHub workflow based on this which would only get executed if a release was cut during job 1. Using something like vsce package --no-git-tag-version <version-from-job-1>.
3. Add the ability of publishing existing *.vsix files without having to package them, to the plugin. So we archive the .vsix inside job 2 and unarchive later to be consumed by the plugin.
4. Document a workflow which would consume the *.vsix files from job 2 and use the feature added in 3 to correctly publish everything to the VSCE Marketplace.

What do you guys think?

[felipecrs]

To aid with 1 and 2, I just created the semantic-release-export-data plugin: https://github.com/felipecrs/semantic-release-export-data.

[felipecrs]

Closed by #280.