Refactor CI/CD builds #456
Conversation
chickenkiller
force-pushed
the
feat/refactor-builds
branch
from
235333c to
9487cff
Compare
There was a problem hiding this comment.
This is awesome! Looks much cleaner. I have a few comments though. And also, do you think it makes sense to propose this against the main branch? I am not sure it needs to be merged only in the release/v0.1 branch, considering it can build for main, release/v0.1 and release/v0.2.
.github/workflows/build-and-push.yml
Outdated
| VERSION=$(git describe --tags --match='v[0-9]*' --always) | ||
| fi | ||
| if [ "$GH_REF" == "release/v0.1" ]; then | ||
| VERSION="v0.1" |
There was a problem hiding this comment.
This is to build the equivalent of nightly for the release branches. So we will have container images tagged:
- garm:nightly
- garm:v0.1.6
- garm:v0.1
- garm:v0.2
I worry that garm:v0.1.6 might be interpreted as being newer than garm:v0.1 whereas garm:v0.1 should in theory hold newer commits than any of the released stable versions.
What do you think?
There was a problem hiding this comment.
so how about we use the tag stable instead of v0.1, and next instead of v0.2 ? We would have these tags:
garm:nightlygarm:stablegarm:nextgarm:v0.1.6- [other releases]
There was a problem hiding this comment.
Another solution is to call the tag v0.1.x instead of v0.1
There was a problem hiding this comment.
both release/v0.1 and release/v0.2 will release "stable" versions. It's just that v0.2.x is in theory a major release (I need to cut v1 at some point to make things easier) and has features/changes that are breaking from v0.1. For example, the garm operator works with v0.1.6. I would like to no longer break it (or any other integrations) for minor releases. So I would like for the release/v0.1 branch to only receive bug fixes and nothing that changes the API.
Eventually, v0.1 will be retired and no new versions will be released from that. But we need to go in parallel for a while to give people a chance to update and test.
Another solution is to call the tag v0.1.x instead of v0.1
As a general housekeeping rule, whenever I release a new stable version, the release/v0.x branch is incremented by 1 and an -alpha suffix is added, until we want to release a new version and we remove the suffix. So if we just released v0.1.6, we would also add a new commit to the release/v0.1 branch and tag that as v0.1.7-alpha. This way we can merge new things in the release branch and the version will appear to be newer.
I aim to do this for all branches (main included). So if we use git describe --tags, we should get a unique, incremental version. I am not sure though how to best mark the container image as "latest"/"nightly" relative to the branch it was cur from (latest v0.1, latest v0.2, etc). Not sure if it's important, either. In general, I would advise people to use stable releases. The "nightly" is for testing and can explode.
There was a problem hiding this comment.
I should probably strive to not let the release branches contain unreleased changes for long. Do you think it's worth having nightlies for release branches if we step up release cadence?
Because we can make this easier that way and just have nightly (main) and stable releases (v0.1.7, v0.2.0 - eventually). Right now, main and release/v0.2 are equivalent.
There was a problem hiding this comment.
I am trying to figure out how we could best do this, and keep it as least confusing as possible.
chickenkiller
force-pushed
the
feat/refactor-builds
branch
from
f932cc4 to
eb07ed3
Compare
|
thanks! |
This P/R makes the workflows a bit cleaner and enable the build and push of 2 versions of garm images.