add version check to ci

[drubin]

Adds a version check to CI this is so we always ensure the package-lock matches the package version before merging. (its happened a few times)

[brendandburns]

@drubin it looks like this didn't work? Because there's version skew but Travis passed...

[itowlson]

It's detecting the version skew and emitting the log message, but not failing the build.

Should we be using process.exit(1)? Though the docs seem to imply that assigning process.exitCode should work.

[itowlson]

It... it couldn't be some sort of horrible operator precedence issue could it? Like when it sees process.exitCode = 1 && console.log(...) it parses it as process.exitCode = (1 && console.log(...)) and because console.log(...) returns undefined that sets process.exitCode to 0 or undefined or something?

You wouldn't do that to us, would you JavaScript? Would you?

[itowlson]

NARRATOR VOICE: It would

(process.exitCode = 1) && console.log(...) appears to work.

[itowlson]

A colleague pointed out that -e does support statements not just expressions so if (...) { process.exitCode = 1; console.log(...); } might be easier for maintainers to read, though it does get a bit verbose.

[drubin]

Sorry, I should have included a better comment, It was something I quickly tried over the weekend. (the failure code worked locally) but for some reason on Travis, it didn't work.

But I will update it a bit later and see. (I will also force a failure so we can check it works)

Sorry for any spam.

[drubin]

A colleague pointed out that -e does support statements not just expressions so if (...) { process.exitCode = 1; console.log(...); } might be easier for maintainers to read, though it does get a bit verbose.

It might be better to just put this in a script and run the script though, then we can have sane comments and run it in other places.

[brendandburns]

@drubin do we need to do anything more here or is this ready to merge?

[drubin]

@brendanburns It wasn't actually failing CI :/ I need to look into it a bit more when I have some time over the weekend, something about how travis handles these error codes and the node not returning them correctly

If you want we can close this and reopen when it's working?

[drubin]

/assign @brendanburns

This seems to work

Failing job (i manually made the version not match) https://travis-ci.org/kubernetes-client/javascript/jobs/503636171

[k8s-ci-robot]

@drubin: GitHub didn't allow me to assign the following users: brendanburns.

Note that only kubernetes-client members and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @brendanburns

This seems to work

Failing job (i manually made the version not match) https://travis-ci.org/kubernetes-client/javascript/jobs/503636171

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[drubin]

/assign @brendandburns

Oops

[brendandburns]

Nice!

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brendandburns, drubin

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [brendandburns]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment