race condition between master and tag builds leads to upload failure

[jabooth]

When we tag a new release two CI builds are kicked off - one for the fact that there is a new commit on master, one for the fact that a new tag build is stated. Sometimes the git clone for the master builds will occur after the tag is placed, and so versioneer still reports the build as a tag. This can be seen here:

https://travis-ci.org/menpo/menpofit/jobs/131907583

We currently don't force the upload of release binaries, which leads to a failure.

It would be better if we had a strategy for such cases. One such strategy would be to add a --force flag to the upload, so existing releases are replaced without complaint. I didn't do this initially as it opens the door to worrying bugs if something goes haywire...maybe there is a better solution? @patricksnape thoughts?

[patricksnape]

Well since a tag should only ever appear once is seems like adding force would be fine. I guess if we built everything properly it wouldn't be hard to recover form a meltdown because we could just kick off a build for each tag again?

[jabooth]

This now crops up again, but with PyPI uploads:

This tag build failed:

https://travis-ci.org/menpo/menpo/jobs/189458933

As the master build of the same tag had already uploaded to PyPI successfully:
https://travis-ci.org/menpo/menpo/jobs/189458855

To be clear this is just an annoying false negative. We could just live with it, would be nicer to resolve though.