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

Org webhooks #1028 #1144

Closed
wants to merge 8 commits into from
Closed

Org webhooks #1028 #1144

wants to merge 8 commits into from

Conversation

nubby109
Copy link
Contributor

#1028 Implemented the Organization Webhook. Added the tests as well. Updated the urls of of repository hooks in some places. Added a ensure condition to check for hookid(added Please Review in comment. Please check if this should be there)

Added the organization webhooks and tests. Corrected a few repository
url (related to hooks). Added a ensure condition for hookid in
repository hooks
@nubby109
Copy link
Contributor Author

6 integration tests I made are failing(All in OrganizationHooksClientTests.cs). I think this is because authenticated user has to be an admin of the organization being managed and OAuth tokens require the admin:org_hook scope.
Need some help, i can't figure out how to go about it.
EDIT- Octokit.Tests tests I added are passing

@ryangribble
Copy link
Contributor

Hey @Anubhav10 thanks heaps for the contribution! Ive done a first pass review and made several comments... Hopefully you don't think Im being overly picky! This is a fantastic contribution and in general you've nailed all the key elements - eg standard and observable implementations, great unit and integration tests, added any new files to all the csproj projects and so on.

In terms of the feedback ive commented - most are around tidy up things like whitespace and I also highlighted a couple of things around consistency in naming/doc - eg http vs https on API doc links, or using organizationName rather than org for the parameters. I realize that there are already some instances of inconsistencies within octokit in these areas but I guess my approach is when adding new work to try to conform with the "majority" consistency, and then hopefully we will also start to tackle the minority items that are inconsistent. You also seem to have made a couple of inadvertent edits to the csproj files around nuget package version and app.config binding redirects etc.

To address a couple of specific things:

  • Your comment about integration tests not running - it looks like you're setting "octokit" org in the test fixture, whereas you should be using a specific integration testing organization that you setup for yourself (accessed via the Helper class). I made a more detailed comment in the location where this was being done
  • With unit tests, when there are parameters that are being checked for empty strings as well as null (eg Ensure.ArgumentNotNullOrEmptyString(organizationName)) you should add a unit test that verifies that. So in your case, you've added the EnsuresNonNullArguments() unit test, but you could also add a EnsuresNonEmptyArguments() test that checks the exceptions are thrown when "" are passed in for the various arguments that shouldn't be allowed (such as the org name). If you search the code base, there should be some other examples of that if you need to see.
  • Your [PleaseReview] comments about NotNull assertions on HookId are not required, as hookId being an int can never be null 😀

@nubby109
Copy link
Contributor Author

Thanks for the review. I'll make these changes as soon as possible. It may take a few days as I have my mid-sem exams in the next week.

@ryangribble
Copy link
Contributor

@shiftkey neither appveyor or travis builds seemed to fire on this one? The fact this is a change about organization hooks and had the "octokit" organisation mentioned in integration tests, hopefully is just a co-incidence! 😀

@shiftkey
Copy link
Member

@ryangribble uh, that's, neat! Will have a look....

@shiftkey
Copy link
Member

@ryangribble I was able to re-send the webhook to AppVeyor but the Travis integration doesn't have that option. Oh well, it should trigger when the PR is next synced...

2. Added EnsuresNonEmptyArguments() in OrganizationHooksClientTest.cs
3. Fixed the integrationTests I added for org webhooks
4. Changes asked by ryanribble
@nubby109
Copy link
Contributor Author

Sorry for the delay. I have made the changes

  1. Changed organizationName to org
  2. Added EnsuresNonEmptyArguments() in OrganizationHooksClientTest.cs
  3. Fixed the problems in integrationTests I added for org webhooks after adding the test account
  4. And other changes as asked by @ryangribble
    About the csproj and app.config changes, there was a problem in the test runner in my VS. It wasn't showing any tests. So, I updated all the Nuget Packages(It was a solution on stackoverflow), it still didn't work. I guess the update made those changes. There was a merge conflict when I commiting this time in the csproj, I have replaced these files with the one in master.

There are references to the documentation in https. Do you want me to change them all?

The integration tests have been skipped for OrganizationMemberClientTest, and the reasons given are "Admin/Member filter doesn't work unless the requester is an organization member" ,"TwoFactor filter can't be used unless the requester is an organization owner". These problems will come in org webhooks too, unless one is the admin of the org the tests will fail, so should I skip them?

One Of the integration test is failing. Test Name: Octokit.Tests.Integration.Clients.OrganizationHooksClientTests+TheCreateMethod.CreateAWebHookForTestOrganization. The reason it is failing is that the 'active' value I send is false, but in the created hook active value is true. I guess this is a problem in the GitHub API.
Also the value of secret is returned as 'HMAC hex digest of the body, using the secret as the key' I guess( there are ******) instead of the secret, so I have commented the assert to check the value of config, and remove the secret for now. This test will pass if we change the active to true in assert check, but that won't be right!! 😀

@nubby109
Copy link
Contributor Author

The travis-ci build is passing this time!! 😀

/// A client for GitHub's Organization Hooks API.
/// </summary>
/// <remarks>See <a href="http://developer.github.com/v3/orgs/hooks/">Hooks API documentation</a> for more information.</remarks>
IObservableOrganizationHooksClient Hooks { get; }
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be in the singular - Hook to be consistent with the other sub-client properties

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added these properties based on the iobservablerepositoriesclient, it was 'Hooks' there. I thought that is how it should be named here too. I'll change it if you want

Copy link
Contributor

Choose a reason for hiding this comment

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

@ryangribble is the master of consistency around here, but I believe that (in a separate PR) IObservableRepositoriesClient (and probably IRepositoriesClient) would need to be changed also

Copy link
Contributor

Choose a reason for hiding this comment

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

Yep, there has been a move towards ensuring all property names for clients are singular (#53 #1035 #1036 #375 #1038),
so I agree these should be IOrganizationHooksClient Hook { get; private set; }

It also makes me realise we have quite a few other clients that still need to get resolved!

Copy link
Contributor

Choose a reason for hiding this comment

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

Opened #1207 to go into this a bit more

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

{
readonly IGitHubClient _github;
readonly OrganizationHook _hook;
private string organizationFixture;
Copy link
Contributor

Choose a reason for hiding this comment

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

local class variable should be named _organizationFixture and be readonly if possible

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@M-Zuber M-Zuber mentioned this pull request Mar 22, 2016
Hooks -> Hook
fixtures-> Fixtures
variable name changes in OrganizationsHooksFixture.cs
@shiftkey shiftkey assigned shiftkey and unassigned shiftkey Apr 4, 2016
@Norbo11
Copy link

Norbo11 commented Jul 31, 2017

Did the organization hooks client get removed at any point, or did it never make it into Octokit? It appears that GitHubClient.Organization.Hooks no longer exists...

@ryangribble
Copy link
Contributor

Hi @Norbo11 this PR was not completed and thus hasn't been merged

@AraHaan
Copy link

AraHaan commented May 6, 2019

So this will allow me to see if GitHub posts to a webhook I want to GitHub application to have to do specific stuff (like checking if the issue that posted to it has a specific label, is a pull request, edits specific files) and posts in it's status/checks?

Currently I got a untested and unrunnable ruby CI that I am not sure will work and I am moving it to .NET Core to C# that I know a lot more on.

@shiftkey shiftkey self-assigned this Sep 16, 2019
@shiftkey
Copy link
Member

Assigning myself to see if we can rebase this on top of master and address those conflicts

@shiftkey
Copy link
Member

I also see #1884 has been opened and might be closer to merging

@shiftkey
Copy link
Member

After a quick glance at #1884, I'm going to close this PR out in favour of the newer as it seems ready to review.

@shiftkey shiftkey removed their assignment Sep 16, 2019
@shiftkey shiftkey closed this Sep 16, 2019
@nickfloyd nickfloyd added Type: Feature New feature or request and removed category: feature labels Oct 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants