You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
The current release process für the OCM CLI and the GH action(s) invoked, are buggy and way to complex. The aim of this epic is to improve the current process. Going on from the next release 0.17.0 we will ALWAYS create at least one release candidate for every new release. The execution of the integration test suite should be included in the release process as quality gate, failing the release in case it cannot be executed successfully.
The new process should be separated into three main parts:
1.) Prerequisites and actions to be done
2.) Release of a release candidate
3.) Promotion of the release candidate
ad 1.) Instead of creating branches and manipulating the VERSION file as part of GH actions, these two actions are done manually by the engineer that creates the release BEFORE the release process is triggered:
checkout main branch and pushing it to the new release branch (for y and z releases)
adopt VERSION file to the release
ad 2.) There should be an idempotent "Release" GH action that can be used to release any kind of release. This action will be triggered on the new branch created and using the information from the VERSION file described in 1.) and creating a release candidate that can be promoted in a subsequent step. The action should include:
creating single assets for all produced build binaries in all supported platforms
creating assets for all metadata like signatures, PEM files, SBOM etc.
creating the CTF that contains all binaries
using the draft release notes from main release <vx.y.z>, labelling them "pre-release" and with a suffix as <vx.y.z>-<rc.n>
execute the integration test suite as quality gate and required to run successful for the complete GH action to succeed
ad 3.) There should be a "Promote Release Candidate" GH action that can be used to promote a release candidate to the final release version. The action should include:
using the RC release, removing the "pre-release" label and setting the "latest" label, making it final
using all, but the CTF asset, 1:1
using the CTF from the pre-release to create the final component version with the final release version (custom code required)
The text was updated successfully, but these errors were encountered:
morri-son
changed the title
EPIC: Clean up and improve GitHub action(s) around the "Release" process
Clean up and improve GitHub action(s) around the "Release" process
Oct 22, 2024
morri-son
changed the title
Clean up and improve GitHub action(s) around the "Release" process
EPIC: Clean up and improve GitHub action(s) around the "Release" process
Oct 22, 2024
morri-son
changed the title
EPIC: Clean up and improve GitHub action(s) around the "Release" process
EPIC: Improve release process
Oct 25, 2024
Description
The current release process für the OCM CLI and the GH action(s) invoked, are buggy and way to complex. The aim of this epic is to improve the current process. Going on from the next release 0.17.0 we will ALWAYS create at least one release candidate for every new release. The execution of the integration test suite should be included in the release process as quality gate, failing the release in case it cannot be executed successfully.
The new process should be separated into three main parts:
1.) Prerequisites and actions to be done
2.) Release of a release candidate
3.) Promotion of the release candidate
ad 1.) Instead of creating branches and manipulating the
VERSION
file as part of GH actions, these two actions are done manually by the engineer that creates the release BEFORE the release process is triggered:VERSION
file to the releasead 2.) There should be an idempotent "Release" GH action that can be used to release any kind of release. This action will be triggered on the new branch created and using the information from the
VERSION
file described in 1.) and creating a release candidate that can be promoted in a subsequent step. The action should include:ad 3.) There should be a "Promote Release Candidate" GH action that can be used to promote a release candidate to the final release version. The action should include:
The text was updated successfully, but these errors were encountered: