Skip to content

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

Closed

Conversation

benjamine
Copy link

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 😮

@benjamine
Copy link
Author

from #278

@AurelioDeRosa AurelioDeRosa added this to the v0.10.8 milestone Jan 24, 2016
// Merge a specific pull request
// -------

this.mergePull = function(pull, message, cb) {
Copy link
Member

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).

@AurelioDeRosa
Copy link
Member

Hi @benjamine. Are you still interested in this PR?

@benjamine
Copy link
Author

@AurelioDeRosa yes, fixing

@benjamine benjamine force-pushed the feature/pull-request-merge branch from fadd687 to 8e1cb4b Compare February 21, 2016 05:25
@benjamine
Copy link
Author

@AurelioDeRosa all fixed except for this comment that got lost while rebasing:

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).

the reason why I added message as a separate (optional) argument is that this allows you to send as first paramenter a pull object obtained from getPull (which will probably the most common case, as you can't create that yourself, github forces you to send the head sha to avoid mistakes)
This is shown in the 2nd example I added to README.
Otherwise you'd have to modify the object in the middle (with a parameter that isn't really part of a pull request info).

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) {
Copy link
Member

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.

Copy link
Author

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.

Copy link
Member

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.

Copy link
Author

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)?

Copy link
Member

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.

Copy link
Author

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

@AurelioDeRosa
Copy link
Member

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 message property. Also, this will help me in the big method refactor I'm planning.

@benjamine
Copy link
Author

besides side effects, it seems confusing to me, as user, to add a pull.message = ... when it's not PR message you're setting (it's a commit message for the merge of such PR).
unless it's called pull.mergeCommitMessage?

@benjamine benjamine force-pushed the feature/pull-request-merge branch from 8e1cb4b to 5481366 Compare February 22, 2016 00:27
@benjamine benjamine force-pushed the feature/pull-request-merge branch from 5481366 to f41ef25 Compare February 22, 2016 00:27
@clayreimann clayreimann modified the milestones: 1.x, 0.12.0 Apr 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy