Automatic CI kickoff

[jasnell]

It would be fantastic if the bot could automatically kick off a new CI run based on a request in comments. For instance, if I posted a comment like: @nodejs-github-bot run CI please.

[addaleax]

How about letting the bot do that when there has not been a previous CI run and the first “approved” review is made? That seems like a reasonably automated way of implementing this to me, but I can’t really tell how tricky that would be.

[phillipj]

That's not too difficult, as far as I know Jenkins has a decent API for triggering builds. My only concern is the reasoning behind the CERTIFY_SAFE option we have to manually check when starting a PR build:

Maybe as long as the approval comes from a collaborator, that is as good as checking the CERTIFY_SAFE option?

[addaleax]

Maybe as long as the approval comes from a collaborator, that is as good as checking the CERTIFY_SAFE option?

Yeah, that’s what I had in mind. Sorry, forgot for a minute that non-collaborators can approve, too ;)

[jbergstroem]

The logical next step would be just starting a job if a committer files a pr, no?

[gdams]

could we not just go down the route of using https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin though? You an admin simply types ok to test and then the CI runs

[gibfahn]

This is something we're looking at for citgm as well. I think what's been suggested so far makes sense, triggering a build when:

• The person who raised the PR has commit access to the project
• Someone who has commit access approves the PR.

I think it would probably be worth having a manual trigger again (e.g. for rerunning CI). Maybe something like github-bot run CI as a comment from someone with commit access?

[jbergstroem]

@gibfahn ..or we could rebuild on any pushes to the branch [again, making the assumption that a committer filed the PR]?

[gibfahn]

@jbergstroem we could definitely do that (I guess as well as the above options rather than instead of?), the only issue would be whether we'd end up doing too many CI runs for branches that are updated frequently.

I guess the other part of this would be for @evanlucas's core-validate-commit module to check whether CI passed (or at least was run). That would help people make sure that CI is run before they merge PRs (assuming people use it).

[gibfahn]

@jbergstroem @phillipj @Fishrock123 So @gdams and I would like to start looking at implementing this for citgm. Is there any Jenkins access we'd need to get this set up?

The plan was to trigger CI runs of this job on new citgm PRs.

[phillipj]

Fantastic!

Yes, sounds like we will have to grant the bot access to Jenkins. The only communication between Jenkins and the bot ATM, is when Jenkins sends requests the bot reporting build statuses for PRs. In other words, there is no communication initiated from the bot to Jenkins.

[gdams]

okay so what's the main steps that we need to follow to set up jenkins to report back to github?

[phillipj]

@jbergstroem knowns what is needed for a Jenkins build to report back to the bot

[gdams]

brilliant thanks

[jbergstroem]

We basically inject a lot of curl as part of the build steps. It's non optimal and at times I actually don't understand why it doesn't work. My preferred approach would be pinging at start/end but also having a process actually monitoring this to verify its results.