Update versioning, introduce changelog and automate publishing #258
Conversation
Use latest version instead of next for demo applications. Should make the apps more stable and avoids confusion, when updating Theia Cloud next versions. Contributed on behalf of STMicroelectronics
Set the version for all components to 0.9.0-next. Reference the 0.9.0-next version for all internal dependencies. In a follow up the builds will be adjusted so that during next builds the git-sha will be appended to the version during publishing. Additionally, the docker images will be pushed to a version- specific next tag (e.g. 0.9.0-next). NPM packages will be pushed with a git-sha attached and to a generic next tag, as 0.9.0-next is not a valid tag for npm packages. Make node/landing-page a npm workspace and remove the usage of `yarn` from the READMEs and node scripts. Contributed on behalf of STMicroelectronics
Provide reuseable workflows for publishing npm packages and docker images. Both will: - Build on PRs for testing. - Publish under the next tag and a specific sha version on main merges. - Publish the version and the latest tag when a releases is published via GH. Note that the next publishing only happens for versions that end with -next. This way release versions (e.g. 0.9.0) are not automatically published when merged to master, instead a release is required. This allows easy creation of patch versions with out merging them on main. Each component has its own workflow that calls the reuseable workflows. These workflows are only triggered when files of that component changed. Contributed on behalf of STMicroelectronics
Introduce changelog and describe versioning in README.md. Contributed on behalf of STMicroelectronics
There was a problem hiding this comment.
Thank you very much. looks very good to me already. I have a few comments I've added inline.
On thing that is missing are release workflows for our demo applications used for testing:
- theiacloud/theia-cloud-demo
- theiacloud/theia-cloud-activity-demo
- theiacloud/theia-cloud-activity-demo-theia
Those were published manually before but we had no CI check workflows on PRs
| run: npm ci | ||
|
|
||
| - name: Build package | ||
| run: npm run build -w ${{ inputs.package_workspace }} |
There was a problem hiding this comment.
If this package would have a dependency to a further package in the npm workspace, I believe the build would fail.
We don't have this case at the moment for packages we want to publish to npm, but if we have some time left we could investigate passing multiple workspaces to this build step.
There was a problem hiding this comment.
Its not the smoothest solutions but you could just append additional -w <packageName> to the ${{ inputs.package_workspace }} parameter.
We could also make the input an array i believe. I will take a look if i still have time after the other improvements.
Always build landing-page container from sources & remove Dockerfile.local. Update vsix and the package-lock of the node/monitor package. Add paths to run the service tests. Make sure last next tag points to release. Create reuseable workflow for manually publishing demo applications. Set Node version to 16.14.0 instead of 16.x. Improve README. Contributed on behalf of STMicroelectronics
Update theia version to latest
Use latest version instead of next for demo applications.
Should make the apps more stable and avoids confusion,
when updating Theia Cloud next versions.
Update components to version 0.9.0-next
Set the version for all components to 0.9.0-next.
Reference the 0.9.0-next version for all internal dependencies.
In a follow up the builds will be adjusted so that during next builds the git-sha will be appended to the version during publishing.
Additionally, the docker images will be pushed to a version-specific next tag (e.g. 0.9.0-next).
NPM packages will be pushed with a git-sha attached and to a generic next tag, as 0.9.0-next is not a valid tag for npm packages.
Make node/landing-page a npm workspace and remove the usage of
yarnfrom the READMEs and node scripts.Update CI to new versions and automate publishing
Provide reuseable workflows for publishing npm packages and docker images.
Both will:
Note that the next publishing only happens for versions that end with -next.
This way release versions (e.g. 0.9.0) are not automatically published when merged to master, instead a release is required.
This allows easy creation of patch versions with out merging them on main.
Each component has its own workflow that calls the reuseable workflows.
These workflows are only triggered when files of that component changed.
Add version section on README + add changelog
Introduce changelog and describe versioning in README.md.
Helm repo PR: eclipse-theia/theia-cloud-helm#45
Contributed on behalf of STMicroelectronics