Travis Integration

[pjcozzi]

There's been some talk about integrating travis-ci to partially automate merging pull requests. Here's some ideas.

• Provide a link to the build so reviewers can test and read the doc without pulling.
• Run the tests. Even if we have to run the non-WebGL tests only to start. We can do better over time with different browsers, platforms, GPU vendors, etc. Perhaps js-test-driver and BrowserStack are useful.
• Publish new releases to npm
• Make the latest version of master available on the website downloads page (Not 100% sure if this is a good idea)
• Warning if the build fails
• Warn if doc build has warnings or errors. The doc build might need some optimizations.
• Run JSHint

Other ideas:

• Run code coverage and warn if coveraged decreased. Or warn if coverage for the new code is poor.
  • Or at least include a link to the build instrumented for coverage so it can be ran manually.
• Is it possible to get reliable test performance? If so, warn if the new/modified tests significantly slowdown the tests.
• If CHANGES.md was not updated, provide a reminder to ask if it needs to be.
• If files were added/removed/modified in ThirdParty and LICENSE.md was not updated, provide a reminder to ask if it needs to be.
• If we don't have a CLA for the github user and the commits are not signed, provide a reminder about the CLA. CC Add CLA information to the repository #574
• Warn if new public members do not have reference doc.

[pjcozzi]

Anyone know how hard this is to do with Travis? @cmorse?

If CHANGES.md was not updated, provide a reminder to ask if it needs to be.

[cmorse]

It would be possible to have a script runs which checks to see if the CHANGES.md file was modified in the pull request and print a message of some kind. But, the problem is that I'm not sure if it is possible to get the GitHub side to say something when it hasn't been updated. I've tried to look through the Travis documentation, but it is pretty sparse.

[pjcozzi]

But, the problem is that I'm not sure if it is possible to get the GitHub side to say something when it hasn't been updated.

That is what I was thinking too. I don't know anything about the GitHub API, but I doubt it lets us change the UI. Perhaps we could request it. In the meantime, I wonder if there is another way to notify the developer that opened the pull request, e.g., via email.

[cmorse]

I don't know anything about the GitHub API, but I doubt it lets us change the UI.

I think the GitHub API allows some changes to the UI. Isn't that how Travis shows the red/yellow/green status on each commit?

What about something that adds a comment to every pull request with a reminder to update CHANGES.md if it hasn't already been changed? http://developer.github.com/v3/pulls/comments/#create-a-comment

[pjcozzi]

Yeap, that would work nicely.

[cmorse]

@pjcozzi I hacked something together real quick using PyGithub: https://gist.github.com/cmorse/6541012
I tested it out on a repository of mine, seems to work pretty well. It would need to run as a cron job or something like that.

[pjcozzi]

Cool! Let's give it a try.

[cmorse]

How would you like to give it a try? I figured you guys could set it up to post from the AnalyticalGraphicsInc account, or something like that.

[pjcozzi]

@cmorse this isn't really my area of expertise, but I was hoping that we could trigger this to run once when a pull request is first opened. Is that possible with the GitHub API? It sounds like you suggest running this on a server and polling all the open pull request once in a while. Do you think that's our only option?

[cmorse]

@pjcozzi As far as I can tell, the Github API only supports polling. I would have preferred to do it with a trigger of some kind as well.

[pjcozzi]

Ugh, I'm not sure that this approach is worth it for us, or at least not worth it yet.

[pjcozzi]

This could be of interest, for example, to check the GitHub username against a database of users who signed the CLA: https://developer.github.com/v3/repos/statuses/

[pjcozzi]

@mramato is there any low-ish hanging fruit here that @ggetz could look at for the code sprint?

[mramato]

Publish new releases to npm

FYI, this is just going to be an automatic part of the build process, and nothing to do with Travis.

[pjcozzi]

Related to #3571.

[pjcozzi]

@mramato OK to close this as duplicate with the ESLint, etc. work @omh1280 is doing this summer?