Publishing and Distribution

[christoph-fricke]

To make this project more usable, the resulting applications should, of course, be published. Where possible, this process should be automated with GH actions.

Publishing the VSCode extension to the VSC marketplace requires a personalized access token (PAT). This token should be stored as a secret named VSCE_PAT in this repository. A MS Azure account is required to create a PAT [guide]. Further, a publisher for the marketplace has to be created [guide]. The publisher should be named kieler, as this name is already used in the extension metadata.

The branch publishing contains a workflow that uses the PAT to publish the extension to the marketplace when a new GH release is published. Further, it add the CLI binaries and extension vsix file as assets to the new release.

The automation around publishing can be tuned in various ways depending on the preferred workflow. The proposed workflow is inspired by my own OS libaries, which use a similiar workflow to auto publish npm packages on new releases.

---

However, this workflow does not take versioning into account (incrementing the versions for each package and creating git tags). It only kicks in, after a version is created. Versioning in a monorepo is highly nuanced with various configurations and degrees of automations. Ranging from manual releases to auto generated changelogs with auto picked semver version and auto release creation. Since this aspect is nuanced and depends highly on preferences and willingness to obey rules for more automation, I decided to pass this decisions to the future, main maintainers and leave it open for discussion.

• Lerna is able to bump versions in a monorepo, handling each package individually: https://github.com/lerna/lerna/tree/main/commands/version#readme
• Lerna is even able to use convetional commits to auto detect the new semver version: https://github.com/lerna/lerna/tree/main/commands/version#--conventional-commits
• Example for a monorepo with independent versioning and highly automated releases, using changesets: https://github.com/davidkpiano/xstate
• A action's job could only be run if the release starts with a specific string, therefore only publishing the VSC extension when the tag of the release starts with "klighd-vscode@": if: startsWith( github.ref, 'refs/tags/releases/klighd-vscode@')
  • See: https://dev.to/calvinallen/git-tag-based-released-process-using-github-actions-5d27

[NiklasRentzCAU]

PAT is secretly stored in the repository, so the repository is now ready for publishing the extensions to the VSCode Marketplace. Generally we are open to further build and release automatisms as described by you, we'll discuss that later.

[christoph-fricke]

Just to complete this issue and to keep it up to date:

The current versioning process uses lerna to version the packages manually, before a new release is published.

The process that should be followed to publish a new release is documented in the wiki: https://github.com/kieler/klighd-vscode/wiki/Releasing-a-New-Version