http://developer.github.com/v3/orgs/teams/

Does this seem like the right signature to have on the interface?

https://github.com/octokit/octokit.net/blob/master/Octokit/IRepositoriesClient.cs#L17

Or should it simply take "nameWithOwner" and we can add an extension method for the split version.

I have found a bug in the Organization Members API Client Conceal method, it is doing a Put instead of a Delete.

So when trying to conceal my membership in an organization it publicizes it instead.

I will send a PR through tonight fixing this issue.

Sorry! 😞

http://developer.github.com/v3/git/trees/

Reference: http://developer.github.com/v3/pulls/comments/

• List comments on a pull request
• List comments in a repository
• Get a single comment
• Create a comment
• Edit a comment
• Delete a comment

We've already implemented the IIssuesClient in Octokit proper, but we created the observable counterparts in Octokit.Reactive.

This should be pretty easy.

We want to have fantastic documentation for Octokit.net. It starts with making sure the public API is documented using XML documentation comments.

This work is easy, but it's tedious. So I'd love to get as much help as we can.

In some cases, the work is very very easy, but just needs to be done.

• If there is documentation on an interface, copy those comments to the implementation. Example, copy comments from IFoo to corresponding members of Foo.
• If a parameter is missing documentation. Copy the documentation from a similar parameter. For example, name when referring to a repository name.
• Add missing method comments by copying and adjusting the docs on the GitHub API website.

IMPORTANT NOTE

We now have a build task that copies comments from an interface to its implementation. So focus on commenting the interfaces and then run a build and you'll magically have the comments on the implementations. :)

I had hoped to get to this, but had other priorities intervene.

http://developer.github.com/v3/issues/comments/

I recently blogged about how our build now validates that a file added to Octokit.csproj is also added to the platform project files such as Octokit-Monotouch.csproj etc.

However, this is still 💩 work. Ideally, contributors would only need to add a file to Octokit.csproj and run a build script (or even better just compile the solution) and we'd automatically add it to the other projects. Or perhaps we generate the other projects. It doesn't really matter as long as the end-result is the same.

Update
I hear that Gyp might be good for this. It requires Python though which our contributors might not have. It could be something our build server runs and does for contributors though.

Hi,

On my machine with VS2013 I get:

File 'Windows.props' not found. See http://go.microsoft.com/fwlink/?prd=12395&pver=1.0&plcid=0x409&ar=MSDN&sar=PlatformMultiTargeting&o1=&o2=Windows for more information.  Octokit-NetCore45

On the VS2012 machine the build is ok.

We should have both annotated code samples and an actual sample application or two.

So far, we've assumed that all endpoints that call JSON require the same Accept header.

But in #47 we learn that the releases api needs a different accept.

Ideally, our users never need to think about this. So I hesitate to add methods for specifying a headers dictionary just yet to any public api.

In fact, we know the right accept header value for releases, we just don't provide a good way to specify it in the ReleasesClient.

So there's a couple ways we could handle this:

1. Specifically allow each client to specify a default accept header.
2. Change ApiConnection methods to allow specifying an accept header.
3. Change ApiConnection methods to allow specifying a headers dictionary.
4. Change our default accept header to have a list containing the two known Accept values we know about. (I believe Accept is a list).

Thoughts?

Generate API docs for Octokit and Octokit.Reactive. Host them online and make them downloadable.

I glanced over how this could tie in with healthcare.gov and inventory panels, and I noticed the usual MIT license stamp, but at the .NET 4.5 grade, that is conflict of interest. I noticed Mono 3.x is mentioned, but the examples use 4.5 code. Rationally, this tells me there is no separation between specific paradigms for target audiences (who either work with or without THEORY). That is what stopped me from further inclusion of this code.

If there is no interest for this science, my work is done.

Reference: http://developer.github.com/v3/pulls/

• List pull requests
• Get a single pull request
• Create a pull request
• Update a pull request
• List commits on a pull request
• [ ] List pull requests files moved to #747
• Get if a pull request has been merged
• Merge a pull request (Merge Button)

This is a follow on from #133 to implement the Observable Orgs Members API Client.

http://developer.github.com/v3/git/blobs/

Looking at the Octokit.rb code, they have the following exceptions for various HTTP codes.

when 400      then Octokit::BadRequest
when 401      then error_for_401(headers)
when 403      then error_for_403(body)
when 404      then Octokit::NotFound
when 406      then Octokit::NotAcceptable
when 415      then Octokit::UnsupportedMediaType
when 422      then Octokit::UnprocessableEntity
when 400..499 then Octokit::ClientError
when 500      then Octokit::InternalServerError
when 501      then Octokit::NotImplemented
when 502      then Octokit::BadGateway
when 503      then Octokit::ServiceUnavailable
when 500..599 then Octokit::ServerError

We've implemented the following so far because these are what we needed.

• AuthorizationException
• TwoFactorChallengeFailedException : AuthorizationException
• TwoFactorRequiredException : AuthorizationException
• ForbiddenException
• LoginAttemptsExceededException : ForbiddenException
• RateLimitExceededException : ForbiddenException

I'm logging this issue for two reasons:

1. To discuss if we want these other ones. I think we do eventually.
2. To serve as low hanging fruit for others who might want to implement these.

http://developer.github.com/v3/git/refs/

During testing I ran into the following:

HTTP/1.1 403 Forbidden
Content-Type: application/json; charset=utf-8
Status: 403 Forbidden

{"message":"Maximum number of login attempts exceeded","documentation_url":"http://developer.github.com/v3"}

We just throw an ApiException in this case. But it might make sense to have a specific ApiForbiddenException.

The question is, should we have one with a Reason enum? Or should we have an even more specific exception type such as MaximumLoginAttemptsExceededException : ApiForbiddenException?

Thoughts?

I want this, so I'm starting on it. It's a bit more involved than some of the others.

http://developer.github.com/v3/search/

See #109 for more details.

Because Octokit.Reactive wraps Octokit, the ObservableGitHubClient ctor simply takes in an IGitHubClient.

But it's time for some REAL TALK™. Nobody is ever going to implement a different IGitHubClient. So perhaps we can add some helpful constructor overloads that instantiat a GitHubClient for the user. Basically the same set of constructors for ObservableGitHubClient that GitHubClient has.

In #46 we decided not to wrap the TaskCancelledException for now. We need to better understand under what conditions can an HttpClient request time out and what exactly happens when it does?

So i started on this spike today using Octokit:

https://github.com/shiftkey/octokit-spike-scriptcs

It'd be nice if we shipped a ScriptPack for Octokit which you could install:

scriptcs -install ScriptCs.Octokit

And then wireup like this (code probably only compiles in my head):

var github = Require<Octokit>();
var client = github.CreateClient("shiftkey-nuke-test-projects", "username", "password");
var repos = client.repository.GetAllForSelected().Result;
...

In #105 I shamefully edited build.bat to create the NuGet packages.

We can and should do something better.

I'd love to get MyGet building our packages, but does anyone know if their build services supports PowerShell?

We should probably update Build-Solution.ps1 to create our packages.

Octokit.Reactive

For Octokit.Reactive, we could probably just point NuGet.exe directly at Octokit.Reactive.csproj and it'd work fine.

Octokit

For Octokit, we can't do that because we have 2 different platforms in there, net45 and netcore45. So we need to build it in a more "manual" approach like we do today. One thing we should do is generate the octokit.nuspec file like we do in RestSharp.

We're doing CI behind GitHub servers currently. It would be nice to move CI to somewhere everyone can see the build results.

From here
http://developer.github.com/v3/gists/#get-a-single-gist

the response will be

{
  "url": "https://api.github.com/gists/5a7e1513d4ad4ef62674",
  "id": "1",
  "description": "description of gist",
  "public": true,
  "user": {
    "login": "octocat",
    "id": 1,
    "avatar_url": "https://github.com/images/error/octocat_happy.gif",
    "gravatar_id": "somehexcode",
    "url": "https://api.github.com/users/octocat"
  },
  "files": {
    "ring.erl": {
      "size": 932,
      "filename": "ring.erl",
      "raw_url": "https://gist.github.com/raw/365370/8c4d2d43d178df44f4c03a7f2ac0ff512853564e/ring.erl"
    }
  },

Note that each file node is named based on the name of the file. In this case the name is ring.erl.

How would this be handled by the octokit deserializer?

http://developer.github.com/v3/issues/events/

Release checklist

Must have for ship

• Check and change secrets
• Ask @jeejkang about where the Octokit.net illustration is (http://octokit.github.io/)
• Update GitHub Pages site (PR is ready to go)
• Blog post

Nice to have

• Private CI while project public (investigate)
• Public CI (Chat room notifications)
• Samples
• Documentation generation

Should we group all the types in Octokit.Reactive into

• Octokit.Reactive
• Octokit.Reactive.Internal

namespaces?

Also, should we get rid of all the unit test namespaces?

Since we're not tying our folder structure to our namespaces and employing a more-or-less flat namespace approach, I'd like to organize our classes into more logical groupings.

Octokit
+ \Models
    + \Request
    + \Response
+ \Clients
   + \Implementation
   + \Interface
+ \Exceptions
+ \Http
+ \Helpers
- GitHubClient.cs
- SimpleJson.cs <-- This is where the NuGet package places it.
- ...

I thought about an approach where each client has its own folder with implementation, models, and interfaces. But we share models across clients. However, we could still do that if you like that better and just put common models in a Models folder.

@half-ogre any thoughts?

The Base Class library packages that are referenced throughout are under a non-open source license. (In fact, they don't even allow usage on a non-Windows OS). This not only prevents Mono users from using the tool but also prevents it's usage in open source projects. The main point of the Bcl inclusions seems to be to use await/async in pre-4.5 .Net. Is there any way we could just avoid using await and async?

http://developer.github.com/v3/git/commits/

http://developer.github.com/v3/git/tags/

Having a default small page size means we might make 3 requests to get all of the repos for a person rather than 1. That could lead to hitting API limits more quickly for some cases.

Is there a reason why async/await is used throughout, when the resulting Task could just be returned directly instead?

For example: https://github.com/octokit/octokit.net/blob/master/Octokit/Clients/UsersClient.cs#L41-L44

public async Task<User> Current()
{
    return await ApiConnection.Get<User>(_userEndpoint);
}

This could just be written as (without async/await):

public Task<User> Current()
{
    return ApiConnection.Get<User>(_userEndpoint);
}

This applies pretty much throughout the codebase.

Code:

  var rel = await gitHubClient.Release.GetAll(organization, repository.Name);

Ex:

System.NullReferenceException : Object reference not set to an instance of an object.
   at lambda_method(Closure, Object, Object)
   at Octokit.PocoJsonSerializerStrategy.DeserializeObject(Object value, Type type)
   at Octokit.Internal.SimpleJsonSerializer.GitHubSerializerStrategy.DeserializeObject(Object value, Type type)
   at Octokit.PocoJsonSerializerStrategy.DeserializeObject(Object value, Type type)
   at Octokit.Internal.SimpleJsonSerializer.GitHubSerializerStrategy.DeserializeObject(Object value, Type type)
   at Octokit.SimpleJson.DeserializeObject(String json, IJsonSerializerStrategy jsonSerializerStrategy)
   at Octokit.Internal.JsonHttpPipeline.DeserializeResponse(IResponse`1 response)
   at Octokit.Connection.<Run>d__3`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Octokit.ApiConnection.<GetPage>d__21`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Octokit.ApiConnection.<>c__DisplayClass9`1.<<GetAll>b__8>d__b.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Octokit.ApiPagination.<GetAllPages>d__0`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

Raw response captured in Fiddler:

https://gist.github.com/andreasohlund/7385114

Ideas?

http://developer.github.com/v3/activity/events/

http://developer.github.com/v3/orgs/members/

Recall, a cold observable is:

a stream that is passive and starts publishing on request.

And a hot observable is:

a stream that is active and publishes regardless of subscriptions.

A great example of this is connecting to a mouse event stream. It wouldn't really make sense to make that cold.

I'm starting to come to the conclusion that for APIs where any method is kicking off an observable (as opposed to connecting to a hot observable), it should be cold.

For example, today, when you call a method to make an HTTP request, it's actually a warm observable. It's hot in the sense that the request occurs whether or not you Subscribe. But it's cold in that the result of the request is published when you subscribe. That makes sense because the Subscribe call could happen after the request completes and you wouldn't want to miss it.

However, having three types of observable makes this shit hard to reason about. Also, certain methods like Retry don't work with warm observables but could work with cold ones.

So the proposal is that we don't make an API request until a Subscribe call happens. What do you think?

/cc @paulcbetts @jspahrsummers

The library should probably have a default user agent if the user doesn't set one. What should it be?

I propose something like this:

string.Format(CultureInfo.InvariantCulture,
                "Octokit.net/{0} ({1}; {2}; {3})",
                OctokitVersion,
                CultureInfo.CurrentCulture.Name,
                environment.Is64BitOperatingSystem ? "amd64" : "x86",
                environment.OSVersion.Version.ToString(3));

This

[Test]
[Explicit]
public async void OctokitTests()
{
    var githubUsername = Environment.GetEnvironmentVariable("OCTOKIT_GITHUBUSERNAME");
    var githubPassword = Environment.GetEnvironmentVariable("OCTOKIT_GITHUBPASSWORD");

    var gitHubClient = new GitHubClient(new ProductHeaderValue("Foo"))
    {
        Credentials = new Credentials(githubUsername, githubPassword)
    };

    var stopwatch = Stopwatch.StartNew();
    try
    {
        await gitHubClient.Issue.Milestone.GetForRepository("Particular", "NServiceBus", new MilestoneRequest { State = ItemState.Closed });
    }
    finally
    {
        Debug.WriteLine(stopwatch.ElapsedMilliseconds);
    }
}

causes, according to fiddler, looping requests on https://api.github.com/repositories/1056713/milestones?state=closed&sort=due_date&direction=asc

I killed mine after ~40 requests sinve i did not want o max my rate limit

What?!

Here's IGitHubClient

public interface IGitHubClient
{
    IConnection Connection { get; }

    IAuthorizationsClient Authorization { get; }
    IAutoCompleteClient AutoComplete { get; }
    IOrganizationsClient Organization { get; }
    IRepositoriesClient Repository { get; }
    IReleasesClient Releases { get; }
    ISshKeysClient SshKey { get; }
    IUsersClient User { get; }
}

Here's IObservableGitHubClient

public interface IObservableGitHubClient
{
    IObservableAuthorizationsClient Authorization { get; }
    IObservableAutoCompleteClient AutoComplete { get; }
    IObservableOrganizationsClient Organization { get; }
    IObservableRepositoriesClient Repositories { get; }
    IObservableSshKeysClient SshKey { get; }
    IObservableUsersClient User { get; }
}

Notice the inconsistencies. All the property names are singular except for Releases. The observable interfaces is missing the Releases property and it has a Repositories property instead of Repository.

I chose singular property names so they map more or less to entities.

For example, here are ways you might interact with a repository:

githubClient.Repository.Get("owner", "name");
githubClient.Repository.GetAllForCurrent();

We should make sure it's all consistent, but I wanted to get some feedback first.

1. Do you like the singular property name approach? Or would you prefer plural?

See the failing integration test, CanListMilestonesWithSortByDueDateDesc

Hi,

readme shows:

but I get:

Is the default constructor missing?