Enable CI/CD for PRs to iojs/website

[kenperkins]

Would be nice to have pull requests to iojs/website automatically trigger a build and deployment to a staging server and then comment in the PR With the link to an ephemeral domain.

[retrohacker]

The concern was raised during the first WG meeting about running untrusted code on a PR. This was in reference to the iojs codebase though.

That being said, with the website repo, I don't see a reason why we couldn't offload the work to TravisCI or Codeship.

[jbergstroem]

I like the approach suggested by @rvagg in our last meeting wrt having trusted collaborators for full runs within our own ci.

[retrohacker]

Would that be overkill for a website repository?

[jbergstroem]

Sorry, I somehow missed that this was only about website. Yeah, overkill indeed.

[retrohacker]

website does not have any unit tests and we do not have access to the settings for that repo. If we did propose this to the website WG, what would be the scope of the build team's involvement?

• Give build team access to website repo to configure and maintain CI.
• Setup CI server for website repo.
• CI ensures gulp task completes without error (no guarantee what it generated is correct).
• Develop unit tests for website repo.
• Deploy upon a successful CI test after merging into master.

[rvagg]

you'd better file an issue over at iojs/website to get buy-in for this, no point in pushing forward if they don't care

[kenperkins]

Good point @rvagg, added nodejs/iojs.org#231

[mikeal]

This is a "nice-to-have" but at the top of our list right now is just to trigger the gulp build on each commit/re-deploy so we can stop checking in "rebuild" commits all the time :)

[kenperkins]

@mikeal I wasn't capturing this necessarily for "right now" but just to make sure it's in an issue. Do we have an issue for auto build on commit?

[jbergstroem]

Arguing that #236 is more relevant and contains more info. Also, auto-testing PR's are ways off. Closing.