-
Notifications
You must be signed in to change notification settings - Fork 777
merge pull request #281
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
merge pull request #281
Conversation
from #278 |
// Merge a specific pull request | ||
// ------- | ||
|
||
this.mergePull = function(pull, message, cb) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're using already an object as the first parameter, instead of using overloading I think it's better to add the optional message as a property of the object. If it isn't defined we can use a default message (e.g. empty string).
Hi @benjamine. Are you still interested in this PR? |
@AurelioDeRosa yes, fixing |
fadd687
to
8e1cb4b
Compare
@AurelioDeRosa all fixed except for this comment that got lost while rebasing:
the reason why I added |
var expectedDocUrl = 'https://developer.github.com/v3/pulls/#merge-a-pull-request-merge-button'; | ||
|
||
repo.getPull(153, function(err, pull) { | ||
repo.mergePull(pull, function(err) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have a test for the success of the merge of a pull request, not the failure. At the moment the test doesn't verify if the method is working correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, but given there's no mocking of the github API, I don't see a way to do merges in a repeatable, parallel-safe, way.
But maybe the test title could be negative then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment we're not doing parallel tests anyway, so the idea here is to create a new PR and then merge it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant parallel in that any user could be running them, locally, or in travis from their forks.
should this create a random commit to a new branch and merge it (with the potential to get conflicts if other is merged in between)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No conflict can happen as the repository used is different at every execution of the tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh ok, good to know, well I'll copy from the create pull request test
I see your point @benjamine and it makes perfect sense. However, I know that in that context a user will not care about the change of the original object with an optional |
besides side effects, it seems confusing to me, as user, to add a |
8e1cb4b
to
5481366
Compare
5481366
to
f41ef25
Compare
adding
repo.mergePull
docs: https://developer.github.com/v3/pulls/#merge-a-pull-request-merge-button
note the unit test isn't really testing a succesful merge (but a failture to merge), given the destructive nature of that action I think that would require mocking of the github API, but that might be a big effort.
ps: this is a pull request to merge pull requests 😮