-
Notifications
You must be signed in to change notification settings - Fork 41
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
set image #90
Conversation
I need to rebase this, will take care of it. |
Separately, @gianarb , please look at the release doc, and see if you see a better way? Maybe we should not use git tags at all, and just have a single version file (maybe it is |
OK, rebase done. The open questions are:
|
That's amazing! Thank you for clarifying the process, I have to be honest it was hard to understand. So many things to generate and background to know. I like the idea to bump the version in a single place. And I think if we use a file like |
So you want to do it in a file, and skip the git tags for now? I am wondering how we would tell GH Actions to know that something is a release? For now, the event is "tag was added". I don't know that it will know how to tell, "a file has changed". Well, I guess we can do some git magic? Or, we can continue to use tags, but use them as an after stage:
And then maybe later get rid of the tag entirely? Or perhaps we have the tag added automatically by gh actions? |
Yeah I have your same unknowns. I am sure can add a step in our I think we have to agree on "the best workflow" we see for this.
I think the unique one for us to get there is via file bump, because of kustomize as you said. If we can figure out how to watch a change on a file via gh action that will be ideal because if t hat happens we can trigger what we already do to create a release in |
OK, will change it for that then. |
Look at it now. The logic is explained in the |
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.
There is already a release file
https://github.com/packethost/cluster-api-provider-packet/blob/master/docs/contribution/release.md
I think I do not understand. I thought about something totally different here. I thought we were speaking about the release of our project. But you were speaking about the cluster-api version our provider supports. If we use this method with the |
Merged the |
You are right. We need to think about this some more. |
The solution doesn't quite work. The releasing part does, but capturing the version does not. |
I think you have to help me clarify what we are solving. I have questions:
I feel like the release process is solved, we can successfully create docker images, tag a release, and upload the yaml files we need. We have to write down the process of supporting the cluster-api versions and the metadata.yaml in practice. I am not convinced about the fact that it has to be automated/generated. |
You are right, this messed it up. Hang tight here, and nice catch. |
I updated it. Take a look. |
This does a few things:
release/
overlay, themanagerless/
overlay, and theresources/
that apply to themtemplates/metadata-template.yaml
to template formattest/metadata.yaml
file for usage in tests, applying the correct versionsdocs/RELEASE.md