-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Facilitate command-line workflow for merging pull requests #177
Comments
@silverwind : now node-merge-commit has drop-downs too. |
@orangemocha looking good. Only thing that's not immediately obvious is 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. |
@silverwind : yes,
Not sure what you mean by that. Every Jenkins slaves clones locally the repo that it's trying to test. |
Related to this issue, I should have mentioned that there is already a mechanism for triggering jobs from scripts.
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. |
Maybe it should default to on? We still have
How about hosting a repo that stays in sync with github master and start off the jenkins job in a |
Or, simpler: use branches on Github itself, with a special |
Yes. I changed it to ON by default.
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? |
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 |
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. |
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 Not sure yet if the Github hooks allow for something like this, but I'll see what I can learn. |
👍 |
I created a webhook in the nodejs/node repo so that @silverwind can experiment with this. |
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 |
@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! |
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. |
As requested by @silverwind at nodejs/node#2598 (comment)
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
The text was updated successfully, but these errors were encountered: