-
Notifications
You must be signed in to change notification settings - Fork 503
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
✨ add release branch protection check #554
Conversation
Signed-off-by: Asra Ali <[email protected]>
Probably an e2e test is best for this, have to check in on how to enable that. The unit tests probably suffice for the check code. |
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
Added unit tests with a nice suggestion from @jeffmendoza. Ready for review! |
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
return checker.MultiCheckResultAnd(checks...) | ||
} | ||
|
||
func getProtectionAndCheck(ctx context.Context, r repositories, l logger, ownerStr, repoStr, |
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.
do you know if this will work when the commitish is a commit hash and not a branch name?
For envoy, for example, one of the releases has commitish "target_commitish": "8fb3cb86082b17144a80402f5367ae65f06083bd"
(see #445)
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.
Nice catch! You get a "404 Branch not found" (nil response and an error) as opposed to if there's no protection, which gives "404 Branch not protected" (resp status not found and an error).
The existing code probably assumed the default branch was always there. Updating so this skips when branches are not found.
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.
so the check will fail if a branch was deleted/does not exist?
In addition, we you could check if a commitish is a hash. If it is, retrieve the name of the branch the commits belongs to, and use the branch name to call getProtectionAndCheck()
.
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.
I refactored to check whether the branch exists with ListBranches. If it doesn't exist/is deleted, it skips.
I'm not sure I can check which branch the commit belongs to. I found references to the github search api, which seems like it's in preview mode.
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.
I refactored to check whether the branch exists with ListBranches. If it doesn't exist/is deleted, it skips.
shall we fail when the commitish points to a non-existing branch, since it provides no information about the protection of the branch that was used? Wdut?
I'm not sure I can check which branch the commit belongs to. I found references to the github search api, which seems like it's in preview mode.
you're right, does not seem to work. An alternative would be to clone the repo and use git branch --all --contains <commit>
. I think it's better to wait for the API above to be more broadly available. Let's check if the commitish looks like a hash and ignore this case for now then. Let's create a github issue to track this for future improvement.
Any better ideas?
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.
I refactored to check whether the branch exists with ListBranches. If it doesn't exist/is deleted, it skips.
shall we fail when the commitish points to a non-existing branch, since it provides no information about the protection of the branch that was used? Wdut?
while looking at envoy, I realized you renamed the master
branch to main
(the new naming that GitHub recommends). With what I suggested above, we would fail the test since the master branch no longer exists. If you go with the solution I suggested, you'll have to treat main and master as being the same branch.
I'm not sure I can check which branch the commit belongs to. I found references to the github search api, which seems like it's in preview mode.
you're right, does not seem to work. An alternative would be to clone the repo and use
git branch --all --contains <commit>
. I think it's better to wait for the API above to be more broadly available. Let's check if the commitish looks like a hash and ignore this case for now then. Let's create a github issue to track this for future improvement.Any better ideas?
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.
Sorry for the delay, was doing a bunch of local testing and ran into some rate limits. To answer the questions:
- Agreed, let's ignore the hash commitish for now (I added a comment TODO to go back later for improvement)
- About the branch rename. Ugh! the Github REST API gives you a 301 moved permanently when you try to get a moved branch (like master). BUT! Go-github does NOT from my testing. It gives you a 404 Not Found, giving me no way to distinguish between a moved and a deleted/non-existing branch. It feels wrong to fail on that. Still trying to see if I can get moved information from go-github.
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.
Sorry for the delay, was doing a bunch of local testing and ran into some rate limits. To answer the questions:
- Agreed, let's ignore the hash commitish for now (I added a comment TODO to go back later for improvement)
+1
- About the branch rename. Ugh! the Github REST API gives you a 301 moved permanently when you try to get a moved branch (like master). BUT! Go-github does NOT from my testing. It gives you a 404 Not Found, giving me no way to distinguish between a moved and a deleted/non-existing branch. It feels wrong to fail on that. Still trying to see if I can get moved information from go-github.
nice finding. I did not know about that! While you investigate, we could file an github issue for go-github to ask about the behavior and whether it'd be a breaking change for them to fix it.
Last resort would be for us to make the http request ourselves :/ Kinda of sad to have to do this, though
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.
Yep, just did! google/go-github#1895
For now just to keep this PR going I'll manually handle the master->main change, and otherwise we'll just fail when the commitish returns a non-existing branch.
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.
done... as much as can do.
@@ -15,7 +15,10 @@ | |||
package checks |
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.
you can also add e2e tests in the e2e/ folder. You can launch make e2e
with an GITHUB_AUTH_TOKEN set for scorecard repo. But you should be able to locally test only the branch protection e2e test (I forgot the exact go command :-))
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.
want to do this in this PR or in a follow-up one? Are there blockers for this? (I know sometimes it's hard to find a repo that actually passes all the tests)
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.
Nice, thanks!
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
Tried this on my own silly repo, that included a master -> main rename
|
Signed-off-by: Asra Ali [email protected]
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
What is the current behavior? (You can also link to an open issue here)
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Other information:
Fixes Feature: Branch-Protection: add support for release branches #445
(although it does not do detection of activity on default branch)