Add release tagging #150
Comments
|
Is there a process that was used previously that worked well we could adopt or should we do something brand new? |
|
I'd say we should take a lot of inspiration from CL here, however, I'd label our current stream as something like This issue interacts with a lot of others, like needing structured metadata. |
Hah, back in the day that's how CL alpha was defined. (Well, coretest, not kola.) |
|
So I was playing around reading this doc and ended up doing: Which...OK I don't quite understand that. Then I did: Which worked but didn't appear to push to the registry - AIUI it's only changing the image stream? I ended up doing: which worked. |
|
I wanted to revisit this issue since we have made some progress in terms I had discussion with @cgwalters and @yuqi-zhang about the path forward and we came
Areas for improvement:
Next Steps:
|
|
I really like this. I'm 👍 on the tagging scheme as well. |
What do you mean, "fragile". If, say, the 4.4837 build failed, you wouldn't be able to regenerate a build with that version number, but that's the point, right? I don't think these have to be sequential. It's useful for bisection that they're monotonic, but beyond that I don't see a need for additional semantic meaning or stability here. Am I missing something? |
Mostly that if our Jenkins instance was destroyed we'd have to either reset the build number by hand, or change the build scripts to to not use the build number. |
|
The idea with #201 is that we'd just tag the oscontainer but yeah, at this point a dupe. |
In an effort to get closer to what has been discussed in openshift#150, the tagging scheme has been changed so that the latest container image out of the pipeline is tagged with `buildmaster` and the commit ID. The usage of the commit ID allows for other parts of the piepline to easily refer to it for other operations.
In openshift#150, it was discussed that an `alpha` tag should be made for the oscontainer (and cloud image) after it passes the tests run in AWS. This change accomplishes this goal by pulling the oscontainer by commit ID, tagging it as `alpha` and pushing it to the registry. (After a successful test, obviously)
In an effort to get closer to what has been discussed in openshift#150, the tagging scheme has been changed so that the latest container image out of the pipeline is tagged with `buildmaster` and the commit ID. The usage of the commit ID allows for other parts of the piepline to easily refer to it for other operations.
In openshift#150, it was discussed that an `alpha` tag should be made for the oscontainer (and cloud image) after it passes the tests run in AWS. This change accomplishes this goal by pulling the oscontainer by commit ID, tagging it as `alpha` and pushing it to the registry. (After a successful test, obviously)
In an effort to get closer to what has been discussed in openshift#150, the tagging scheme has been changed so that the latest container image out of the pipeline is tagged with `buildmaster` and the commit ID. The usage of the commit ID allows for other parts of the piepline to easily refer to it for other operations.
In openshift#150, it was discussed that an `alpha` tag should be made for the oscontainer (and cloud image) after it passes the tests run in AWS. This change accomplishes this goal by pulling the oscontainer by commit ID, tagging it as `alpha` and pushing it to the registry. (After a successful test, obviously)
In an effort to get closer to what has been discussed in openshift#150, the tagging scheme has been changed so that the latest container image out of the pipeline is tagged with `buildmaster` and the commit ID. The usage of the commit ID allows for other parts of the piepline to easily refer to it for other operations.
In openshift#150, it was discussed that an `alpha` tag should be made for the oscontainer (and cloud image) after it passes the tests run in AWS. This change accomplishes this goal by pulling the oscontainer by commit ID, tagging it as `alpha` and pushing it to the registry. (After a successful test, obviously)
In an effort to get closer to what has been discussed in openshift#150, the tagging scheme has been changed so that the latest container image out of the pipeline is tagged with `buildmaster` and the commit ID. The usage of the commit ID allows for other parts of the piepline to easily refer to it for other operations.
In openshift#150, it was discussed that an `alpha` tag should be made for the oscontainer (and cloud image) after it passes the tests run in AWS. This change accomplishes this goal by pulling the oscontainer by commit ID, tagging it as `alpha` and pushing it to the registry. (After a successful test, obviously)
In openshift#150, it was discussed that an `alpha` tag should be made for the oscontainer (and cloud image) after it passes the tests run in AWS. This change accomplishes this goal by pulling the oscontainer by commit ID, tagging it as `alpha` and pushing it to the registry. (After a successful test, obviously) If the AWS tests fail, the image tagged with the ostree commit is garbage collected and no alpha promotion happens.
In openshift#150, it was discussed that an `alpha` tag should be made for the oscontainer (and cloud image) after it passes the tests run in AWS. This change accomplishes this goal by pulling the oscontainer by commit ID, tagging it as `alpha` and pushing it to the registry. (After a successful test, obviously) If the AWS tests fail, the image tagged with the ostree commit is garbage collected and no alpha promotion happens.
In an effort to get closer to what has been discussed in openshift#150, the tagging scheme has been changed so that the latest container image out of the pipeline is tagged with `buildmaster` and the commit ID. The usage of the commit ID allows for other parts of the piepline to easily refer to it for other operations.
In openshift#150, it was discussed that an `alpha` tag should be made for the oscontainer (and cloud image) after it passes the tests run in AWS. This change accomplishes this goal by pulling the oscontainer by commit ID, tagging it as `alpha` and pushing it to the registry. (After a successful test, obviously) If the AWS tests fail, the image tagged with the ostree commit is garbage collected and no alpha promotion happens.
In an effort to get closer to what has been discussed in openshift#150, the tagging scheme has been changed so that the latest container image out of the pipeline is tagged with `buildmaster` and the commit ID. The usage of the commit ID allows for other parts of the piepline to easily refer to it for other operations.
In openshift#150, it was discussed that an `alpha` tag should be made for the oscontainer (and cloud image) after it passes the tests run in AWS. This change accomplishes this goal by pulling the oscontainer by commit ID, tagging it as `alpha` and pushing it to the registry. (After a successful test, obviously) If the AWS tests fail, the image tagged with the ostree commit is garbage collected and no alpha promotion happens.
In an effort to get closer to what has been discussed in openshift#150, the tagging scheme has been changed so that the latest container image out of the pipeline is tagged with `buildmaster` and the commit ID. The usage of the commit ID allows for other parts of the piepline to easily refer to it for other operations.
In openshift#150, it was discussed that an `alpha` tag should be made for the oscontainer (and cloud image) after it passes the tests run in AWS. This change accomplishes this goal by pulling the oscontainer by commit ID, tagging it as `alpha` and pushing it to the registry. (After a successful test, obviously) If the AWS tests fail, the image tagged with the ostree commit is garbage collected and no alpha promotion happens.
In an effort to get closer to what has been discussed in openshift#150, the tagging scheme has been changed so that the latest container image out of the pipeline is tagged with `buildmaster` and the commit ID. The usage of the commit ID allows for other parts of the piepline to easily refer to it for other operations.
In openshift#150, it was discussed that an `alpha` tag should be made for the oscontainer (and cloud image) after it passes the tests run in AWS. This change accomplishes this goal by pulling the oscontainer by commit ID, tagging it as `alpha` and pushing it to the registry. (After a successful test, obviously) If the AWS tests fail, the image tagged with the ostree commit is garbage collected and no alpha promotion happens.
Right now we don't tag releases, and our CI doesn't gate anything.
Our first step here should be having kola or whatever actually be involved in promoting a tag.
We also need an explicit tagging/promotion model of e.g. "alpha/beta/stable".
The text was updated successfully, but these errors were encountered: