Make note to wait for travis to finish before tagging

[raboof]

otherwise the build on master might also use the tag

[dwijnand]

Thanks. It's been a long-standing problem I've failed to find a good solution for (to the point I think sbt-dynver is not a good solution 😲)

[raboof]

I think sbt-dynver is still fine, and this should be fixed at the Travis side: it should be able to distinguish between a build triggered by a push to master and a build triggered by a tag being added. I see there's a TRAVIS_TAG environment variable (https://docs.travis-ci.com/user/environment-variables/), I wonder if that is populated when the trigger was a push but a tag was added to that commit since?

[dwijnand]

Let's say, best-case scenario, it's not, how do you use that to fix the problem?

[raboof]

Only do the 'release' step when TRAVIS_TAG is populated?

[dwijnand]

That could work for some projects, but in the sbt plugins I've set up I release tags and master builds ("merglies"), so I still run into this problem.

Fundamentally git tags are un-versioned mutable state that shouldn't transparently change build behaviour, IMO. So I think a better set up is one where git tags just fast-fail a build if they don't match the version (and great lengths would go into removing or minimising version micro-management).

I explored these thoughts with Daniel Spiewak in djspiewak/sbt-spiewak#3.

[raboof]

I release tags and master builds ("merglies")

Good point.

I explored these thoughts with Daniel Spiewak in djspiewak/sbt-spiewak#3

Also https://github.com/djspiewak/sbt-spiewak/blob/master/versioning.md - interesting!

[pvlugter]

Sorry, I read the comment earlier about separating out the commit and tag, and still forgot about it when I actually pushed.

[dwijnand]

Here are some other notes with a workaround: sbt/sbt-dynver#118