Skip to content
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

Implemented IUserEmailsClient GetAll and Add methods #323

Merged
merged 16 commits into from
Feb 10, 2014

Conversation

pmacn
Copy link

@pmacn pmacn commented Jan 23, 2014

Did not implement the Delete method as it is a DELETE that sends a request body.
http://developer.github.com/v3/users/emails/#delete-email-addresses

Not unheard of but still rather unorthodox especially since the body identified the resources to delete. So maybe it's time to start a lobbying group for that as well? If it's not something that's likely to change I'll go ahead and add the required infrastructure methods to handle deletes with a body, but would at least want to check first.

cc @pengwynn
Because you seem to be one of the people to call on for all things GitHub API

@pmacn
Copy link
Author

pmacn commented Jan 23, 2014

Also looks as if this was already implemented in a different pull request.
Should have checked and not just put my trust in the list :)

@shiftkey
Copy link
Member

@pmacn I really need to go back and revive those PRs that are languishing there, unloved...

@pmacn
Copy link
Author

pmacn commented Jan 23, 2014

I'll update this to just add the Add method, however the current implementation has it sitting on the UsersClient and I created a separate UserEmailsClient for it.
Do we want to keep them on the UsersClient or should it be on a separate client as the API structure would suggest?

@pmacn
Copy link
Author

pmacn commented Jan 23, 2014

I really need to go back and revive those PRs that are languishing there, unloved...

Their cries keep me up at night!
If it helps at all I can have a look at some of the ones that aren't mine and at least give a 👍 or 👎 (I could possibly even be nice and give suggestions/comments rather than just a thumbs down)

@@ -99,22 +99,4 @@ public class TheUpdateMethod
Assert.Equal(HttpStatusCode.Unauthorized, e.StatusCode);
}
}

public class TheGetEmailsMethod
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plans to bring back this integration test?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, there was a reason for this being out and I thought I put a comment in about it. I was obviously mistaken.
What I wanted to do was to try and replace it with something that would pass for everyone. Maybe simply check that it returns an email at all?
I guess another option would just be to have anyone who wants to run these change the email on their test account?
(Not sure if that's doable and it might leave a lot of test accounts with forgotten and un-retrievable passwords? :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe simply check that it returns an email at all?

👍 Let's start simple and go from there

@pmacn
Copy link
Author

pmacn commented Feb 2, 2014

Sorry about the delay haven't been able to get around to it until now.

/// <summary>
/// Gets all email addresses for the authenticated user.
/// </summary>
/// <returns></returns>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finish up the returns elements here and I think this is ready to 🚢

Peter MacNaughton added 8 commits February 2, 2014 15:57
EmailAddress.DebuggerDisplay
default implementation. Still needs delete method which is skipped
because it's a HTTP DELETE. There's currently nothing in the
ApiConnection to handle this scenario and it's a rather unorthodox thing
to support.
delete.
This only tests the GetAll method at this point. Would like to have
Delete implemented before testing Add so that we can do cleanup.
@pmacn
Copy link
Author

pmacn commented Feb 8, 2014

I think this has everything in it now. Except for the Delete method not being implemented because of the issues mentioned above.

  • Client
  • ReactiveClient
  • Documentation comments
  • Unit tests
  • Integration tests
  • DebuggerDisplay on EmailAddress.

@pmacn
Copy link
Author

pmacn commented Feb 8, 2014

I'm receiving the following two errors when trying to run build.cmd all of a sudden

Running build failed.
Error:
System.Exception: Start of process C:\Windows\Microsoft.NET\Framework\v4.0.30319 failed. Access is denied
   at Fake.ProcessHelper.ExecProcessWithLambdas@68-16.Invoke(String message)
   at Fake.ProcessHelper.ExecProcessWithLambdas(FSharpFunc`2 configProcessStartInfoF, TimeSpan timeOut, Boolean silent, FSharpFunc`2 errorF, FSharpFunc`2 messageF)
   at Fake.MSBuildHelper.build(FSharpFunc`2 setParams, String project)
   at Fake.MSBuildHelper.MSBuildWithProjectProperties@271.Invoke(String project)
   at Microsoft.FSharp.Primitives.Basics.List.iter[T](FSharpFunc`2 f, FSharpList`1 x)
   at Fake.MSBuildHelper.MSBuildWithProjectProperties(String outputPath, String targets, FSharpFunc`2 properties, IEnumerable`1 projects)
   at Fake.MSBuildHelper.MSBuild@281-1.Invoke(IEnumerable`1 projects)
   at FSI_0001.clo@60-5.Invoke(Unit _arg5) in E:\Git\octokit.net.backup\build.fsx:line 61
   at Fake.TargetHelper.runTarget@290(String targetName)

and

  1) System.Exception: Start of process C:\Windows\Microsoft.NET\Framework\v4.0.30319 failed. Access is denied
   at Fake.ProcessHelper.ExecProcessWithLambdas@68-16.Invoke(String message)
   at Fake.ProcessHelper.ExecProcessWithLambdas(FSharpFunc`2 configProcessStartInfoF, TimeSpan timeOut, Boolean silent, FSharpFunc`2 errorF, FSharpFunc`2 messageF)
   at Fake.MSBuildHelper.build(FSharpFunc`2 setParams, String project)
   at Fake.MSBuildHelper.MSBuildWithProjectProperties@271.Invoke(String project)
   at Microsoft.FSharp.Primitives.Basics.List.iter[T](FSharpFunc`2 f, FSharpList`1 x)
   at Fake.MSBuildHelper.MSBuildWithProjectProperties(String outputPath, String targets, FSharpFunc`2 properties, IEnumerable`1 projects)
   at Fake.MSBuildHelper.MSBuild@281-1.Invoke(IEnumerable`1 projects)
   at FSI_0001.clo@60-5.Invoke(Unit _arg5) in E:\Git\octokit.net.backup\build.fsx:line 61
   at Fake.TargetHelper.runTarget@290(String targetName)

@pmacn
Copy link
Author

pmacn commented Feb 8, 2014

Apparently the above two messages was because I had a custom environmental variable set called MSBUILD that pointed to that directory. Something I had set up for a different build.

Client and ObservableUserEmailsClient
};
var client = new ObservableUserEmailsClient(github);

var email = await client.GetAll();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rx note: when you await on an observable you're doing the same thing as a .First() (which is now deprecated in Rx).

The test itself is just checking we get something back, which is fine, but just something to watch for. If you wanted all the results, you could await client.GetAll().ToArray()

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which is now deprecated in Rx

Wasn't aware that it's been deprecated. I'll just make the test more Rxish in a separate PR.
But yes, my intention with the test was just to see that we got at least one EmailAddress back.

shiftkey added a commit that referenced this pull request Feb 10, 2014
Implemented IUserEmailsClient GetAll and Add methods
@shiftkey shiftkey merged commit 70996fa into octokit:master Feb 10, 2014
@pmacn pmacn deleted the user_emails_client branch February 11, 2014 03:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants