Update bin/release to create releases in draft state

[awh]

From bin/release:

    echo "== Creating GitHub release $RELEASE_NAME $VERSION"
    # This cannot be done as a draft because of a bug in
    # github-release: https://github.com/aktau/github-release/issues/7
    github-release release \
        --user $GITHUB_USER \
        --repo weave \
        --tag $LATEST_TAG \
        --name "$RELEASE_NAME $VERSION" \
        --description "$RELEASE_DESCRIPTION"

github-release/github-release#7 has been addressed, so we can update our release script accordingly.

[rade]

Adding a --draft does indeed work now; I have successfully published a draft release to my own github account.

But there's a problem...

We also publish a latest_release release. This is of vital importance since all our stable download URLs point at the weave script in that release. In order to publish that release, we first need to delete the existing latest_release. If we add a --draft to the release creation that follows then all the download URLs are broken until the draft status is removed. Conversely, if we don't add the --draft to latest_release, we end up with latest_release referencing (in its description, and the weave script release artifact) an unpublished release. This doesn't break anything but does beg the question of what the point is of creating the versioned release with --draft. After all, the new release is already visible via latest_release, and thus via the main download links.

I suppose we could add a third stage (on top of 'build' and 'publish'): 'promote', which would publish the latest_release release. This would go part way to addressing #909.

[rade]

We could make the publish/promote distinction deeper by shifting everything to do with latest_release, e.g. tagging with latest_release, and publishing of docker images with the latest tag, to the promote step.

[awh]

We could make the publish/promote distinction deeper by shifting everything to do with latest_release, e.g. tagging with latest_release, and publishing of docker images with the latest tag, to the promote step.

@squaremo you left the comment in the bin/release script that this issue is meant to address - do you have any thoughts on splitting publish into two steps? Seems reasonable to me - the only concern I have is that if the steps are separated by any length of time (e.g. whilst the draft is reviewed) it's possible that you could end up uploading a different binary to latest during weave promote. Perhaps we could mitigate that by downloading the script from $LATEST_TAG and reuploading that as latest, rather than uploading whatever we've lying around in releases/$LATEST_TAG?

[awh]

OK I'm playing around with a modified version of the release script that has three steps:

• build
  • Finds latest annotated tag (I've dropped the requirement for it to begin with a 'v' to address make the release script support non-mainline releases #909; not sure if this is a good idea - perhaps we should have an explicit flag to permit this)
  • Clones repo
  • Assert version in changelog (modified to allow freeform version tags)
  • Version inject/build/test
  • Check weaver version (modified to allow freeform version tags)
• publish
  • Finds latest annotated tag (as above)
  • Check tag with same hash exists in github
  • Check version release doesn't already exist in github
  • Create draft version release and upload binary (for non-mainline releases which won't be promoted, perhaps an explicit flag to publish to create the release with --pre-release instead of --draft?)
• promote
  • Finds latest annotated tag (as above)
  • Check latest tag matches latest_release
  • Check latest_release exists in github with correct hash
  • Remove latest_release from github if it exists
  • Remove draft status from version release
  • Create latest_release and upload binary

TL;DR: support freeform version tags and all the latest_release update machinery has been moved into a third step. latest_release tag should now be updated between publish and promote, and only for mainline releases.

Thoughts @squaremo @dpw? This should mean you can build/publish a non-mainline release, or build/publish/promote a mainline release with an opportunity to review between publish and promote...

[awh]

for non-mainline releases which won't be promoted, perhaps an explicit flag to publish to create the release with --pre-release instead of --draft?

If we did this, we could make promote refuse to work with --pre-release releases to prevent accidental promotion

[awh]

New proposal:

release build
release draft [--pre-release]
release publish

The second step creates the GitHub release in draft state, optionally marked as pre release; the final step removes the draft state (making the release visible to the outside world) and updates latest in {Git,Docker}Hub only if the pre release attribute is missing. Thoughts?