-
Notifications
You must be signed in to change notification settings - Fork 578
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
Add workflow for regular (nightly or weekly) releases #4949
Comments
/triage accepted |
One thing that could be tricky here is solving where the container images associated with the release land. We likely will not be able to use Another challenge will be cleaning up the images; I don't think we want to keep all of them especially if there are nightly releases. We'll have to decide on how long we'll keep a nightly or weekly around once cut. |
+1 We will also need to figure out whether we want to add them as actual draft releases in the Release section of the Repo, or if we can deal with this differently. I would be interested in understanding how CAPV and upstream CAPI deals with this at the moment. Maybe @sbueringer @chrischdi @fabriziopandini can provide some more details on how the process looks like there. |
We don't do actual releases. The GitHub action is just there to ensure the make target keeps working. What we do though is publishing nightly manifests & images to GCS |
Which is also something that CAPA seems to be doing, or at least trying :D
|
Looked at the log of the jobs: https://storage.googleapis.com/kubernetes-jenkins/logs/cluster-api-provider-aws-push-images-nightly/1782680957447311360/artifacts/build.log Looks pretty good already. I would just recommend to change the location of the manifests. See: kubernetes-sigs/cluster-api#10489 I'll mention it in core CAPI office hours tomorrow, if you have some questions that you want to ask directly there. |
@sbueringer I see, I didn't know that, thanks a lot! As you suggested I opened: #4952 I will open a separate PR to improve the docs on how to use nightlies. Thanks again! |
See kubernetes-sigs/cluster-api#10521 also as we work towards this. |
#4748 automated releases with GoReleaser. We can build on this configuration by making regular releases via another workflow. These could be nightly or weekly, depending on CI availability.
This gives us more regular build signal, and versions that users can test out.
CAPV has weekly automated releases (that don't seem to get published), as does upstream CAPI.
These will need to be generated as pre-release GitHub releases to prevent
clusterctl
picking them up. So #4927 will need to be fixed first.The text was updated successfully, but these errors were encountered: