Enable inline Jenkins build status on PRs

[phillipj]

Opening this issue continuing a discussion ignited over in nodejs/github-bot#82.

Before I start fiddling around with getting Jenkins to report build statuses to the github-bot, I want to confirm which build we should do this on? I'm assuming citgm-continuous-integration or citgm-smoker?

Would you agree that we can start off by setting up Jenkins to report build status to a PR specified when starting a build, like we do in nodejs/node, or do you have something else in mind?

/cc @gibfahn @gdams

[gdams]

So we want to be using the citgm-continuous-integration job and they way I view this working is that we get a new PR in, we then comment @github-bot run ci or something when we know that they PR is safe to run and then the job is kicked off. When that happens we obviously want to set the citgm variable as the branch so for example gdams/citgm#testFork. We also want to run the ci on several node versions so at the moment we test travis on v4, v6 and v7 so there should be 3 job runs that should be reported back to GitHub

[phillipj]

Hm, okey... I'll describe what happens for nodejs/node for reference:

1. A collaborator starts a node-test-pull-request job, specifying the PR # (and ticks post build status to PR checkbox)
2. Whenever a child job starts, fails or succeeds it sends a HTTP request via curl to the @nodejs-github-bot
3. We had some issues with Jenkins specifying the latest commit sha in a given PR #, so @nodejs-github-bot requests github.com finding the latest sha
4. Lastly the bot uses the node-github package to set the inline PR status, which is really done by specifying a status on the latest sha in that PR/branch. The content of the status is provided by Jenkins, bot really just acts as a github.com proxy for Jenkins to use.

In other words there is very little magic done in @nodejs-github-bot this far to accomplish what we have in nodejs/node.

Could we start off by doing the same for citgm, and improve with kicking off CI by commenting later or does that sound way off what you have in mind?

[gibfahn]

Starting with what we have in core makes sense, it also means any changes we make can then easily be added to core if necessary.

[gdams]

SGTM, I assume you're going to need to edit the Jenkins job?

[phillipj]

Yes. I'll start by making a copy of the current integration job and adjustments making it more similar to nodejs/node and we'll take it from there.

[gdams]

@phillipj perfect. Can you set the job up so that it runs 3 jobs, ie v4, v6 & v7 on each PR?

[gdams]

feel free to DM me on twitter and I'll help you set it up :)

[phillipj]

There's even some progress made in getting the bot aware of comments it gets mentioned in: nodejs/github-bot#128

[gibfahn]

@phillipj #394 (comment) this is very cool. One question, at the moment the bot says:

@gibfahn build started: https://ci.nodejs.org/job/citgm-continuous-integration-pipeline/

It'd be cool if it had the build number as well, so https://ci.nodejs.org/job/citgm-continuous-integration-pipeline/37/ , not sure how easy that would be.

[phillipj]

Nice!

Completely agree about the comment made by the bot. Atm it's like that because Jenkins doesn't respond with the build number, seems to have been implemented that way because of the async nature of triggering (read quieing) a build. I assume we can improve that by polling Jenkins for a while after the API request was made, to figure out what number the most recent build would get.