Facilitate command-line workflow for merging pull requests

[orangemocha]

As requested by @silverwind at nodejs/node#2598 (comment)

How about introducing an alternative CLI-only workflow like this:

• Pull commits to local repo
• Rebase and modify the commits
• Push changes to a special CI branch which kicks off the tests and if it's green, it gets commited with all - original information intact.

From the Jenkins perspective, this should be pretty easy, we just need to provide a way to trigger node-merge-commit from CLI, and possibly provide an additional parameter to delete the source branch at the end of the run.

/cc: @nodejs/jenkins-admins

[orangemocha]

@silverwind : now node-merge-commit has drop-downs too.

[silverwind]

@orangemocha looking good. Only thing that's not immediately obvious is APPLY_CHANGES. Is that like a dry-run when left off?

Regarding this issue: Jenkins does host its own git repo, right? I think it'd be better to just use these repos instead of Github's, if there's a way to keep keys with push access in sync.

[orangemocha]

@silverwind : yes, APPLY_CHANGES is a dry-run when left off. Everything is the same except for nothing is pushed to GitHub.

Jenkins does host its own git repo, right?

Not sure what you mean by that. Every Jenkins slaves clones locally the repo that it's trying to test.

[orangemocha]

Related to this issue, I should have mentioned that there is already a mechanism for triggering jobs from scripts.

Trigger builds remotely
Enable this option if you would like to trigger new builds by accessing a special predefined URL (convenient for scripts).
One typical example for this feature would be to trigger new build from the source control system's hook script, when somebody has just committed a change into the repository, or from a script that parses your source control email notifications.
You'll need to provide an authorization token in the form of a string so that only those who know it would be able to remotely trigger this project's builds.

Those tokens enable triggering jobs, so they should be considered as sensitive as a Jenkins user passwords. With proper care though, they might already enable doing everything that you need.

[silverwind]

APPLY_CHANGES is a dry-run when left off

Maybe it should default to on? We still have node-test-commit for pure CI runs.

mechanism for triggering jobs from scripts

How about hosting a repo that stays in sync with github master and start off the jenkins job in a post-receive hook?

[silverwind]

Or, simpler: use branches on Github itself, with a special merge- prefix in the branch name. If such a branch is pushed to, it should first wait a few minutes in case more is pushed, and then start off the job after a certain period of inactivity. If that is possible.

[orangemocha]

Maybe it should default to on? We still have node-test-commit for pure CI runs.

Yes. I changed it to ON by default.

How about hosting a repo that stays in sync with github master and start off the jenkins job in a post-receive hook?

It sounds like an interesting idea but I am not sure I understand the details. When you push to mirror-repo:master, it would trigger a job to merge changes into node:master? Or how does it know which repo/branch to merge into? And how would it synchronize if multiple collaborators were to push multiple updates to the same branch?

[silverwind]

When you push to mirror-repo:master, it would trigger a job to merge changes into node:master? Or how does it know which repo/branch to merge into? And how would it synchronize if multiple collaborators were to push multiple updates to the same branch?

I think one branch per job is necessary. Targeting a repo/branch is a hard question, one could get fancy with the branch name like merge-node-master-pr1234 or merge-node/v0.12-pr1234 (if slashes are valid branch names), but that's a extra bit of information everyone has to remember, hmm.

[orangemocha]

Right, one branch per job is necessary. Even though I like the idea of the post-receive hook (it feels like pushing to the repo manually, and it leverages GitHub for authentication), encoding all the parameters in a branch name seems too complicated. A script could do all of it easily and then trigger the job.

I'll email you the authorization token to trigger the job from a script, so you can experiment at will.

[silverwind]

I guess it's fine if this only covers merges to master. I'm thinking the simplest way to accomplish it are special branches on Github, so the guidline would be to push the changes to merge-pr-1234 where 1234 is the ID of the PR, so the script can possibly report back the status of the merge on the PR itself.

Not sure yet if the Github hooks allow for something like this, but I'll see what I can learn.

[orangemocha]

👍

[orangemocha]

I created a webhook in the nodejs/node repo so that @silverwind can experiment with this.

[silverwind]

The current plan is to push to special branches on Github and a node app at the end of that webhook watches for these branches and triggers the node-merge-commit job. The app itself doesn't have commit access to the repo, and merging/deleting branches would all be done by Jenkins.

[silverwind]

@orangemocha I don't think I'll get motivated enough to complete this merge proxy thing in the near future. You can remove the webhook you've set up for me!

[orangemocha]

I have marked the webhook as inactive. Closing this issue for now. We can revisit once we resume the experiment with automated merging of pull request.