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

Github appends :master to context #107

Closed
cswendrowski opened this issue Jul 16, 2019 · 2 comments
Closed

Github appends :master to context #107

cswendrowski opened this issue Jul 16, 2019 · 2 comments
Labels
documentation The issue is due to bad documentation question Further information is requested

Comments

@cswendrowski
Copy link

cswendrowski commented Jul 16, 2019

When using status_check_context: "policy-bot",

Github ends up sending a webhook with the payload

"context": "policy-bot: master",
"description": "All rules are approved",

policy-bot then doesn't recognize the context as matching and triggers off it's own event, creating an infinite loop of processing and causing a failure

  "context": "policy-bot: master",
  "description": "'policy-bot[bot]' overwrote status to 'failure'",

Swapping the context to policy-bot: master unfortunately isn't a workaround:

  "context": "policy-bot: master: master",
  "description": "'policy-bot[bot]' overwrote status to 'failure'",

I am using the latest Dockerhub image of policy-bot and Github Enterprise 2.17

Checking the payload, it looks like it's more appropriate to check the installation section of the payload:

  "installation": {
    "id": 5,
    "node_id": "MDI..."
  }
@bluekeyes
Copy link
Member

I'm sorry that you've run into just about every issue with getting policy-bot configured! Thanks for working through it while we get the docs into a better place.

In this case, what is the value of the options.app_name option in your server configuration? I believe you are hitting this audit check, which should ignore the bot's own statuses, provided the app_name is set correctly (it should be policy-bot in your case.) The exact value of the context doesn't matter, since the bot only checks the prefix.

That said, validating by something less error-prone like the installation ID sounds like a good idea, so I'll look into if that is possible.

For background, the target branch name is included in the status context to prevent a security flaw where you could open a PR to a non-protected branch with a bad policy, get a fake approval on your commit, and then update the PR to point at a protected branch while retaining the fake approval.

@bluekeyes bluekeyes added question Further information is requested documentation The issue is due to bad documentation labels Jul 16, 2019
@cswendrowski
Copy link
Author

No worries! I appreciate that you are providing a useful tool to the community and supporting those who need help getting it running. You've saved me a bunch of time trying to write this myself.

My app_name was previously set to Policy Bot which is how it is configured in Github:
image

I'm guessing your code actually reads the url value instead, where it is policy-bot
image

After updating to policy-bot as my appname, I finally am getting checks on my PR's:
image

Thanks again for all the help! Do you guys have a tipjar?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation The issue is due to bad documentation question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants