Code coverage and automatic publishing on npm

[astorije]

• Sorry @tripu, I took the liberty to merge Changes to the Travis configuration #154 myself, but I had a good intention: it wasn't compatible with this current PR and I merged it only so that I could rebase this one before you woke up and so that you can merge and release without conflicts :-)
• Code coverage can be run via npm run coverage, thanks to istanbul.
• The README badge for code coverage is updated after Travis builds, via the command above and coveralls, so no need to worry about this :)
• Travis also takes care of automatically deploying on npm after a successful build, only when a new tag is pushed. To publish, according to the doc, one must:
  1. Have a clean repo (aka no changes that are uncommitted)
  2. Run npm version (major|minor|patch)¹ to (a) increment by 1 the according version number, (b) commit the change of version in package.json, and (c) create a tag in git, called vx.y.z.
  3. Run git push --follow-tags (do not run git push --tags) to push the commit and the tag altogether, and Travis will take it from there.
• If the npm password changes, the encrypted api_key must be regenerated with (the lines start with a whitespace on purpose to not appear in the bash history):

 echo -n "w3c:password" | base64
 travis encrypt (result_of_the_previous_command)

¹ For the next deployment, you'll want to jump directly from version 0.4.0 to 1.0.0. That can be done by directly running npm version 1.0.0.

[astorije]

BTW, deployment will be triggered only if the build is successful, which might not happen due to CSS validator tests failing from time to time :-/

[tripu]

@astorije, setting up the code coverage feature was a great thing. But those automated comments from Coveralls reporting random, marginal changes after every single commit are annoying, and don't add anything but noise.

Are they necessary to keep the badges up-to-date?

I've been reading a bit about Coveralls, looking for options to mute the Coverall bot for our project. But didn't find any. Do you know if it's possible?

Another solution would be to trigger the Coveralls job in Travis only after a new tag is created, or at least only after a PR is merged. That would keep the bot more quiet.

Your thoughts?

[astorije]

Hi @tripu! Agreed, these comments are really noisy, I wanted to ask you if you wanted to keep them or remove them today :-) Anyway, I gladly disabled the option through the settings on the coveralls website. We don't need to do anything more to keep the badge updated. Sorry I didn't do disable that in the first place.

Otherwise, do you plan to create the 1.0.0 version soon? That'd be great to close a PR on Echidna and make sure we don't miss Specberus updates...

[astorije]

By the way, the nice and braggy npm and license badge will be populated only after specberus makes it on npm :D

[tripu]

Done, @astorije!

I wasn't sure if we should wait to merge those two pending PRs before tagging 1.0.0… But I was working on Echidna right now, and noticed that there a few other PRs that depend on Specberus being in npm, as you rightly say.

https://www.npmjs.com/package/specberus

[astorije]

I think it's fine, because releasing a new version is just a matter of npm version (minor|patch) && git push --follow-tags so we can release a new patch version after every PR, almost, and not care about the rest :-)

Aren't you thrilled by your cool new badges? :D

By the way, I wonder if the [](https://travis-ci. glitch on the npm page is because of the missing description in package.json.

[tripu]

You working on branch astorije/coverage, @astorije?

[astorije]

Oops, sorry @tripu, I made a completion mistake and forgot to delete. Good catch, but damn you saw that fast! :-)

[tripu]

@astorije, I have to say that I keep coming to this PR after the years, just because I seem incapable of remembering the simple sequence

npm version (major|minor|patch)
git push --follow-tags

!!

😊

[astorije]

Ah, thanks for the kind words, @tripu!

If you're any interested about this, I have since then moved a way a little from this model:

• I now use Yarn
• I now ask Travis to do the release for me: create a tag/release from GitHub, and let Travis do the rest. See this for an example. When GitHub Actions are a little more of a thing, I might just switch to that. Hard to keep up with the times, you know :D