operator/build: fix tagging consistency#71
Conversation
Tags are being published this way so this is the syntax that should be used. I inadvertently was using non-prefixed tags in my personal repo, and so missed this.
| string(name: 'TAG', | ||
| defaultValue: 'v0.0.0', | ||
| description: 'CLUO tag to release'), | ||
| booleanParam(name: "PUSH_LATEST", |
There was a problem hiding this comment.
What's the rationale for this? Can we just decide to always have a "latest" tag that is the most recent published version or just never have one.
There was a problem hiding this comment.
The reason to not push latest is e.g. if you push a release branch for an older version.
Say we have 1.2.0 and 1.3.0, and you then release 1.3.1 but need to backport 1.2.1 as well. In that case, :latest should not be changed.
There was a problem hiding this comment.
This would also be true for e.g. '-alpha` releases
There was a problem hiding this comment.
Then let's not have latest at all. We don't really want real clusters using the "latest" tag and for development we can build locally.
There was a problem hiding this comment.
That was the original plan, see #70 (review) for why this changed
There was a problem hiding this comment.
You're right and I generally agree, but the ship has sailed. at this point
There was a problem hiding this comment.
Ok, I still don't think that means we're committed to updating a "latest" forever though - we can stop at any point and earlier is better.
There was a problem hiding this comment.
If you want to make a PR moving the example to use the latest published version I can delete that commit from this happily enough.
TBH I'd even be okay with deleting the :latest tag and just feeling really bad about the backwards incompatibility since it's only been there for a couple weeks.
2 participants
cc @dghubble, this is the proper fix for the problem we ran into on the installer.
Specifically, the first commit.
The other two are build improvements that are somewhat related, but not all that much.