ojcelis
commented
1 year ago What we are currently doing, are the below steps when we may need to stagger the release due to issues in containers:
- Build another RC release from RC branch (includes the recent containers changes)
- Test the containers with the build above
- Kick of TSC vote
- Promote the RC build and force sign
- Create updates on github.io and merge it.
- Copy containers artifacts including its signatures to the current release repo (libs-release-local/org/zowe/x.x.x e.g. x.x.x = 2.10.0)
- Merge the containers changes from RC branch to Master branch
- Update documentation (if any)
Currently, the zowe release pipelines are one-shot actions that releases many artifacts:
The one shot pipeline bakes in many assumptions as part of its release, one of which is that you always release everything or nothing. There are multiple validation and post-release steps that work on this assumption and break in the case of partial releases.
There are times where we may need to stagger the release of certain artifacts, and it would be nice if the Zowe release pipeline could accommodate those situations. One example recently was 2.6.x containers: we had a bug impacting only containers, which are not an LTS deliverable, so the community voted to release 2.6 LTS components without containers and to release 2.6 containers when a fix was present. We could not use the standard release pipelines for the catch-up container release, due to assumptions. In breaking these assumptions and supporting finer-grained releases, we risk complicating the tracking and historical record of release artifacts in source code as well as publication, and each artifacts relation to the others.
A suggested starting point: allow the following granularities:
all[default],zos-only,containers-only,client-only. Here, client includes CLI, Plugins, and SDKs.