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

✨ add release branch protection check #554

Merged
merged 12 commits into from
Jun 15, 2021
Merged

Conversation

asraa
Copy link
Contributor

@asraa asraa commented Jun 8, 2021

Signed-off-by: Asra Ali [email protected]

  • Please check if the PR fulfills these requirements
  • 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)

@asraa
Copy link
Contributor Author

asraa commented Jun 8, 2021

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.

@asraa asraa marked this pull request as ready for review June 10, 2021 18:59
@asraa
Copy link
Contributor Author

asraa commented Jun 10, 2021

Added unit tests with a nice suggestion from @jeffmendoza. Ready for review!

checks/branch_protected.go Outdated Show resolved Hide resolved
checks/branch_protected.go Outdated Show resolved Hide resolved
Signed-off-by: Asra Ali <[email protected]>
return checker.MultiCheckResultAnd(checks...)
}

func getProtectionAndCheck(ctx context.Context, r repositories, l logger, ownerStr, repoStr,
Copy link
Contributor

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)

Copy link
Contributor Author

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.

Copy link
Contributor

@laurentsimon laurentsimon Jun 11, 2021

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().

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 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.

Copy link
Contributor

@laurentsimon laurentsimon Jun 11, 2021

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?

Copy link
Contributor

@laurentsimon laurentsimon Jun 11, 2021

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@laurentsimon laurentsimon Jun 15, 2021

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

Copy link
Contributor Author

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.

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... as much as can do.

@@ -15,7 +15,10 @@
package checks
Copy link
Contributor

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 :-))

Copy link
Contributor

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)

Copy link
Contributor

@azeemshaikh38 azeemshaikh38 left a comment

Choose a reason for hiding this comment

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

Nice, thanks!

@asraa
Copy link
Contributor Author

asraa commented Jun 15, 2021

Tried this on my own silly repo, that included a master -> main rename

$ ./scorecard --show-details --checks Branch-Protection --repo=github.com/asraa/asraa.github.io
Starting [Branch-Protection]
Finished [Branch-Protection]

RESULTS
-------
Repo: github.com/asraa/asraa.github.io
Branch-Protection: Fail 10
!! branch protection not enabled for branch branch1
!! branch protection - EnforceAdmins should be enabled on main
!! branch protection - Linear history should be enabled on main
!! branch protection - Status checks for merging should be enabled on main
!! branch protection - Stale review dismissal should be enabled on main
!! branch protection - Owner review should be enabled on main

@inferno-chromium inferno-chromium enabled auto-merge (squash) June 15, 2021 16:35
@inferno-chromium inferno-chromium merged commit ceef465 into ossf:main Jun 15, 2021
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.

Feature: Branch-Protection: add support for release branches
4 participants