Managing Multiple Projects and Artifacts - DevOps-MBSE/AaC GitHub Wiki

Purpose

The purpose of this document is to identify and document methods for managing and releasing multiple artifacts to multiple artifact repositories and indexes.

Releasing AaC Python

The AaC Python package is released to PyPi, and is already being deployed. The Python package and VSCode Extension have loosely couped versioning simply by them sharing an interface. Because the versions don't have to be tightly coupled, we should not couple the deployment of the artifacts.

We should continue the pattern of similar but separate workflows for the projects.

Publishing VSCode Extensions

Publishing VSCode extensions to the VSCode Marketplace and OpenVSX Registry can be handled easily with the HaaLeo/publish-vscode-extension. Or, both registries provide NPM packages that can publish the packages to the corresponding registry.

VSCode Marketplace requires an Azure DevOps pipeline as well as a Microsoft Publisher API Token to enable publishing to Microsoft VSCode Marketplace. Microsoft will verify plugin publishers, however, they require a project domain including some DNS configuration.

OpenVSX Registry has an unclaimed/unverified extensions process which will allow us to publish the extension to the marketplace with an API Token. OpenVSX won't verify the extension until we claim the extension namespace via a pull-request to the OpenVSX repo.

Automation Abilities

Github workflows have a number of events that can be used to trigger workflows. Some notable events are:

The release event allows us to trigger workflows based on changes to the state of Github Releases.

The milestone event allows us to trigger workflows based on changes to the state of milestones, which could be handy in automating github releases at the end of each sprint.

Leveraging Github Releases as triggers

Github provides an interface for managing project/artifact releases in the repository. These github releases can be automatically created when a pull-request is merged into the main branch. These releases can be easily created with the action-automatic-releases github action.

The automated github releases can act as a person-in-the-loop control while allowing us to automate the rest of the release process. By leveraging the published state for release events, then we can automate the deployment of artifacts when we publish a Github Release.

Version Bumping Considerations

If we utilize the action-automatic-releases github action, then we can automatically set the release's version to be the Python or VSCode extension's version number, but the main branch workflow will have to be updated to handle these extra steps and delineate between the Python and VSCode extension artifacts/projects.

If we leverage the branch event for PR -> Main, then we will need to implement either a check for existing github release with the same version, or have a strong manual process to ensure that the project's version is updated in the PR prior to being merged to the Main branch.