Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions HACKING.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,12 +26,14 @@ Once a release has been created, it can be pushed:
To cut an official tag release, we generally use the images built by [ci.openshift.redhat.com](https://ci.openshift.redhat.com)
under the openshift3_ami job.

1. Make sure the "openshift3_ami" job is passing
1. Pause the merge queue by disabling the "process_pull_requests" job on [ci.openshift.redhat.com](https://ci.openshift.redhat.com)
1. Create a new git tag `git tag v0.X.X -a -m "v0.X.X" HEAD`
2. Push the tag to GitHub `git push origin --tags` where `origin` is `github.com/openshift/origin.git`
3. Run the "openshift3_ami" job
4. Once the images are pushed to the repository, run `OS_PUSH_TAG="v0.X.X" hack/push-release.sh`. Your tag must match the Git tag.
5. Upload the binary artifacts generated by that build to GitHub release page
6. Send an email to the dev list, including the important changes prior to the release.
1. Tag the images that previously passed in the "openshift3_ami" build by running `OS_PUSH_TAG="v0.X.X" hack/push-release.sh`. Your tag must match the Git tag.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically at this point I commented out the openshift/origin at https://github.com/openshift/origin/blob/master/hack/push-release.sh#L42. The reason for this is that the binary built inside the images has the previous tag built in. That could cause the origin image to pull down the wrong images.

I suspect there's something wrong in my tagging process. It seemed weird to have to tag docker images before the git code. However, like I mentioned, when I did it in the opposite order it would cause test failures. @smarterclayton, any idea what I missed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After I rebuilt the "openshift3_ami" job I would then tag the "openshift/origin" image to the correct version. I'm guessing that's not the way you do it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have to tag first in git, then run an ami job, then once that passes, pull and push the images.

1. Push the tag to GitHub `git push origin --tags` where `origin` is `github.com/openshift/origin.git`
1. Select the last passing "openshift3_ami" job and click "Rebuild". This is why it's important to pause the merge queue. Otherwise another pull request could land. This could lead to the git tag and the Docker image tags becoming out of sync. However, if you push the tag before images exist with the corresponding tag in the Docker hub you will get test failures.
1. Upload the binary artifacts generated by that build to GitHub release page
1. Send an email to the dev list, including the important changes prior to the release.

We generally cut a release before disruptive changes land.

Expand Down