-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: Release process #1871
doc: Release process #1871
Conversation
stevenhorsman
commented
Jun 18, 2024
- Rework our release process documentation based on the change of process in CoCo
05e206f
to
2d981a1
Compare
- Pre-release testing | ||
- Cutting the release | ||
- Post release tasks | ||
1. The CoCo operator updates to use references to the other component releases and then releases itself |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the operator release needs to happen after the CAA stuff, we should add something to the release checklist.
Is the step required in the operator for peer pods just bumping the payloads in the remote CRD yaml?
I guess the important question is whether there is something we should be waiting for for this release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So for this release bumping the operator first is fine as we had to roll back the changes to get the peerpod controllers managed by the operator, but if/when we resolve the challenges there we would need to do peer pod before the operator, so we can update the peer pods references like Pradipta did in confidential-containers/operator#362
64980d2
to
9d5d484
Compare
9d5d484
to
bdc664b
Compare
*github.com/confidential-containers/operator/config/samples/ccruntime/peer-pods* URLs: | ||
``` | ||
operator_commit=<latest operator commit sha> | ||
sed -i "s#\(github.com/confidential-containers/operator/config/default\)#\1?ref=${operator_commit}#" Makefile |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will end up running:
kubectl apply -k "github.com/confidential-containers/operator/config/default?ref=${operator_commit}"
Does it work if ${operator_commit} is a commit SHA1? Asking because I never tried that...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a great point - I'm not sure I've ever tried that either. Something to add to the list. For this alpha release we can pick the v0.9.0-alpha1 tag anyway as the operator has already released
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @stevenhorsman !
Nice. Tested it and works with any commit SHA:
$ kubectl apply -k "github.com/confidential-containers/operator/config/default?ref=34ebaa6c564f30e7fe94aba8a332a8abe12da020"
namespace/confidential-containers-system created
customresourcedefinition.apiextensions.k8s.io/ccruntimes.confidentialcontainers.org created
serviceaccount/cc-operator-controller-manager created
role.rbac.authorization.k8s.io/cc-operator-leader-election-role created
clusterrole.rbac.authorization.k8s.io/cc-operator-manager-role created
clusterrole.rbac.authorization.k8s.io/cc-operator-metrics-reader created
clusterrole.rbac.authorization.k8s.io/cc-operator-proxy-role created
rolebinding.rbac.authorization.k8s.io/cc-operator-leader-election-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/cc-operator-manager-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/cc-operator-proxy-rolebinding created
configmap/cc-operator-manager-config created
service/cc-operator-controller-manager-metrics-service created
deployment.apps/cc-operator-controller-manager created
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. You are a ⭐!
- Rework our release process documentation based on the change of process in CoCo Signed-off-by: stevenhorsman <steven@uk.ibm.com>
bdc664b
to
27ce8b9
Compare
sed -i "s#\(github.com/confidential-containers/operator/config/samples/ccruntime/peer-pods\)#\1?ref=${operator_commit}#" Makefile | ||
``` | ||
|
||
<!-- TODO, should we worry about updating the e2e test reference in ../src/cloud-api-adaptor/test/provisioner/provision.go too? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory yes. But I'm working on a PR to read from versions.yaml on both Makefile and provision.go. Let's keep this as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds great. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for long time to review it @stevenhorsman . It looks great!