avoid publishing binaries on git tags

[mapsam]

If you release a new version of a node-cpp-skel library, and use the same commit to build a git tag, it's likely travis will run two jobs and try to build binaries for both jobs. This leads to failing tests based on which jobs can publish binaries first. Workflow:

• update package.json and commit to master with the following commit (example version) 0.3.3 [publish binary]
• this kicks off a travis job on the master branch
• immediately after pushing to master, run git tag -v v0.3.3 -m 'v0.3.3' and git push --tags
• this kicks off another travis job based on the tag, but uses the most recent commit message which is 0.3.3 [publish binary]
• this means there are two jobs running with the same publish binary message, and each individual matrix will either pass or fail depending on whether the other job has published binaries.

This isn't hyper critical, but makes tests fail.

cc @springmeyer @GretaCB

[mikemorris]

The workflow I've used for publishing binaries on git tags was:

npm version [patch | minor | major]
git push && git push --tags

This will automatically increment the version in package.json and create a commit with the message 0.3.3 and a v0.3.3 tag pointing to that commit, but only the tag should trigger a binary build (by checking TRAVIS_TAG, CIRCLE_TAG (like in https://github.com/mapbox/mapbox-gl-native/blob/master/platform/node/scripts/after_success.sh#L8) or a CircleCI job filter.

I was not using the [publish binary] commit message hook except when I needed to manually delete and republish a binary for a previously-published version.

[springmeyer]

We could add a check to

node-cpp-skel/scripts/publish.sh

Line 38 in c3d13e7

if [[ $(is_pr_merge) ]]; then

to skip publishing if a tag is detected.

Automatically publishing only on tags as @mikemorris is something to consider. The benefit is avoiding needing to use the [publish binary] commit message. The potential drawbacks are:

• If a build fails (one job or many, it happens) you have to create a new tag. Having to create a new tag due to travis network failure, for example, feels non-ideal.
• we frequently use the [publish binary] to create testing binaries for a given gitsha and don't need a formal tag/permanent reference. Being forced to use tags could be seen as good for documenting development work, but also litters the tags display with lots of things most users don't care about. To the extent that the tags display should list all the official releases, this is non-optimal

[sssoleileraaa]

Thanks for explaining the benefit of having the [publish binary] commit message hook for publishing test binaries as well (used it a couple times while working on a feature branch of vt-shaver-cpp).

I was going to suggest using mason since we're already used to using mason publish but that would add another dependency which isn't so great.

The more @GretaCB and I discussed the different scenarios of this issue the more I like Dane's suggestion, which I believe is saying that we could skip an s3-publish during a tag --push if the latest commit message on master is a [publish binary].

[springmeyer]

Ran into another odd case where a commit attempted to publish when it should not have. The commit message was something like:

Integrate Expressions (#148)

* port to latest mbgl - refs #65

* [publish binary]

And publishing was triggered even though [publish binary] was not in the first line. I suspect it might be the * in the commit message body.

[springmeyer]

landed in #139