-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Protected Branches updates - main methods #1441
Conversation
So far only non reactive client and unit tests
…pdate request that doesnt take a restrictions parameter
- fix Update method PUT parameters - add [SerializeNull] to various request fields - fix deserialize problem with ProtectedBranchRestrictions ctor not being public - tidy up DebuggerDisplay output
…eRepositoryBranchesClient Add unit tests for Observable methods
} | ||
|
||
[DebuggerDisplay("{DebuggerDisplay,nq}")] | ||
public class BranchProtectionRequiredStatusChecks |
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.
XMLDocs for consistency?
Apart from (possibly) a couple of missing XMLDocs, the code looks good to me 👍 |
Looks good to me! |
@shiftkey let me know if you want to 👀 this over or if you're happy for me to merge based on @alfhenrik's review |
@@ -23,6 +25,9 @@ public class TheGetAllMethod | |||
{ | |||
Assert.NotNull(branch.Protection); | |||
} | |||
|
|||
// Ensure Protected attribute is deserialized (at least master branch should be true) | |||
Assert.True(branches.Any(x => x.Protected)); |
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.
Could we make this test assert the state of master
and 🔥 this comment?
@ryangribble just gave it a look over, a few little comments but nothing serious 👍 merge at your leisure |
Ive fixed the comments and 💄 just waiting for any suggestions on that comment regarding a nicer |
Change team and user lists to specific classes derived from Collection<T> so we can offer better configuration of BranchProtectionPushRestriction via multiple ctors (teams only, users only, teams and users, etc) Add another ctor to BranchProtectionPushRestrictions for the case where no teams/users are specified (ie admin only) Change organization update tests to use this new ctor and assert we get empty lists rather than no push restrictions
OK ive implemented the user and team push restrictions settings be classes derived from // Only admins can push
new BranchProtectionPushRestrictionsUpdate();
// Specify some teams that can push
new BranchProtectionPushRestrictionsUpdate(
new BranchProtectionTeamCollection { "my-team1", "my-team2" });
// specify some users that can push
new BranchProtectionPushRestrictionsUpdate(
new BranchProtectionUserCollection { "user1", "user2" });
// spceify both teams AND users that can push
new BranchProtectionPushRestrictionsUpdate(
new BranchProtectionTeamCollection { "my-team1", "my-team2" },
new BranchProtectionUserCollection { "user1", "user2" }); |
Also I realise some of the names are pretty verbose (eg |
@ryangribble that all seems great ✨ |
Closes #1407
The updates to Protected Branches preview API added a significant number of new endpoints allowing granularity in setting each segment of the branch protection settings separately.
For an MVP (Minimum Viable Product) approach, this PR implements only the top level methods, which will enable octokit.net users to manage all aspects of BranchProtection from that top level. If there is need/desire, the other more granular methods can be added in separate PRs
This PR implements the following methods: