microsoft / pvscbot

GitHub bot for Microsoft/vscode-python

Purpose

This bot exists to automate the development process/workflow for https://github.com/microsoft/vscode-python. It also acts as a simple demo of a GitHub bot running on Azure.

This bot is what is known as an OAuth app and is not a GitHub app. The differences come down to simplicity in authentication and how widely can the bot be deployed. Since this bot is only deployed for a single repository and the original author was intimately familiar with OAuth apps that was the route taken.

This bot also predates GitHub Actions being released. As such some things this bot does may be easier to do as an action.

Currently the bot will do the following things for you:

1. Add/remove the classify label based on whether any other status label is set.
2. When an issue is closed, remove any status-related labels, e.g. needs PR (with the idea that if an issue is re-opened then it needs to be re-evaluated as to why the issue is still open).

Deployment

Generically

On the deployment/hosting side

You must set two environment variables for the bot to function:

1. GH_SECRET: secret between GitHub and your bot.
2. GH_AUTH: Auth token for the bot to make changes in your repo.

The shared secret between GitHub and your bot is used to verify that the webhook payload actually originated from GitHub for your repository and isn't malicious. This is important as a malicious user could send fake webhook payloads to your bot and cause it to make changes on the malicious user's behalf.

The personal access token is to empower your bot to make changes to your repo on your behalf. You can use a token from your personal GitHub account or create a fake bot account. Make sure the token has the following scopes/permissions:

1.repo:public_repo (if your repo is public; adjust accordingly for your needs)

On the GitHub side

When creating the webhook you need to specify what events to send to your endpoint. This bot supports the following events:

1. Issues

Azure

The bot is currently written to support Azure Functions running on Python 3.7.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

pvscbot's Issues

When a question is asked, label issue as "info needed"

Would probably need to have a template form, like Question for @...: in order to trigger the bot to add the label and know when to remove the label when the other person responds.

When an issue is labeled 'in progress' & not in a milestone, assign to the current milestone & add 'unplanned'

If a PR is closed but not merged, change issue to 'needs PR' or 'in progress' as appropriate

Which label depends on whether the issue is assigned.

When an issue is labeled as 'needs upstream fix', copy issue to appropriate project

This would require pvscbot being added to Microsoft/ptvsd and Microsoft/python-language-server. But it would let us control how we copy things.

We can lock the issue once copied and leave a comment that future details should go to the issue on the other repo.

If the other repos are monitored then we could check if the first line of the issue is Microsoft/vscode-pyon# and if so then close the corresponding issue on vscode-python.

Set up continuous deployment

Add type hints everywhere

It would be great to eventually run mypy under --strict.

This does not apply to the tests.

Ignore errors when removing a label fails

2019-01-03T00:53:13.357665628Z Traceback (most recent call last):
2019-01-03T00:53:13.357682028Z   File "/home/site/wwwroot/pvscbot/__main__.py", line 35, in main
2019-01-03T00:53:13.357687228Z     gh, router, request.headers, body, secret=secret, logger=logging
2019-01-03T00:53:13.357691528Z   File "/home/site/wwwroot/pvscbot/ghutils/server.py", line 13, in serve
2019-01-03T00:53:13.357695728Z     await router.dispatch(event, gh, logger=logger)
2019-01-03T00:53:13.357699928Z   File "/home/site/wwwroot/antenv/lib/python3.7/site-packages/gidgethub/routing.py", line 80, in dispatch
2019-01-03T00:53:13.357704228Z     await callback(event, *args, **kwargs)
2019-01-03T00:53:13.357707928Z   File "/home/site/wwwroot/pvscbot/github/classify.py", line 55, in added_label
2019-01-03T00:53:13.357712028Z     event.data["issue"]["labels_url"], {"name": labels.Status.classify.value}
2019-01-03T00:53:13.357716128Z   File "/home/site/wwwroot/antenv/lib/python3.7/site-packages/gidgethub/abc.py", line 155, in delete
2019-01-03T00:53:13.357720128Z     jwt=jwt, oauth_token=oauth_token)
2019-01-03T00:53:13.357723928Z   File "/home/site/wwwroot/antenv/lib/python3.7/site-packages/gidgethub/abc.py", line 82, in _make_request
2019-01-03T00:53:13.357727928Z     data, self.rate_limit, more = sansio.decipher_response(*response)
2019-01-03T00:53:13.357731728Z   File "/home/site/wwwroot/antenv/lib/python3.7/site-packages/gidgethub/sansio.py", line 326, in decipher_response
2019-01-03T00:53:13.357735728Z     raise exc_type(*args)
2019-01-03T00:53:13.357739528Z gidgethub.BadRequest: Label does not exist

Traceback makes no sense for classify; just pay attention to the fact that it called into delete for gidgethub.abc.

When an external contributor open a PR, thank them & let them know we will get to them next sprint

When an issue is marked 'in progress' is unassigned, assign the label adder

Parameterize tests for when not to muck with 'classify' label

E.g. make sure both 'data science' and 'release plan' work.

When a PR has been merged, label the corresponding issue w/ 'validate'

Remove 'triage' label when another status label is added

If a label type is missing, add an 'incomplete' label

• needs -> type
• type -> feature
• type-bug -> reason
• needs upstream fix -> upstream

If any of these relationships are missing then an incomplete label should be added. (Technically there's also one for all issue requiring a status label, but "classify" takes care of that.)

When an external contributor opens a PR, label issue & PR as 'external contributor'

Due to the fact that the contributor may not have included a news file, the issue # may need to be grabbed from the opening comment. It also means potentially needing to watch for comment edits.

When an issue is closed, remove "info needed"

Check if any labels already exist before adding the 'classify' label

E.g. microsoft/vscode-python#3862 was created through ZenHub and had labels, but because the webhook for the issue creation lacked any labels the bot added it blindly. Doing a quick check of what the labels are before adding the label should help with the race condition.

Gate on mypy passing

Upgrade dependencies

E.g. uritemplate should be 3.3.0.

Set up CI

Add linting of PRs

Enforce Black formatting.

When 'triage' label added, automatically assign the issue to a team member

Add the 'type-bug' label to issues with no 'type-*' label

If #55 isn't feasible, add type-bug as the default type label for new issues (along with classify).

When issue is labeled 'needs PR' and is assigned, change label to 'in progress'

When the 'triage' label is removed, unassign the issue

Add the "type-bug" label to issues filed directly from VS Code

Add the type-bug label to issues filed via the "Report an Issue" command in VS Code, maybe by checking if the issue body starts with Issue Type: <b>Bug</b>

Automate "needs decision"

If an issue has the "needs decision" label added, then:

1. Add a canned response about how to upvote the issue
2. Have that canned comment link directly to the opening comment to help make clear that people should 👍 on that issue and not the canned response
3. Add a seeding 👍 on the opening comment

When a new status label is added, remove the old one

This is a generalization of #4 . The potential issue with this is needs upstream fix is to needs PR like info needed is to triage on occasion. That would mean changing needs upstream fix to act more as a modifier rather than a stand-alone status label.

Move to Python 3.8 and Azure Functions 3

https://azure.microsoft.com/en-us/updates/announcing-general-availability-python-3-8-support/

Check for copyright header on new files from team members

Gate on 100% test coverage

Using logging.exception() incorrectly

2019-01-03T00:53:13.357754428Z Traceback (most recent call last):
2019-01-03T00:53:13.357758128Z   File "/home/site/wwwroot/antenv/lib/python3.7/site-packages/aiohttp/web_protocol.py", line 390, in start
2019-01-03T00:53:13.357762128Z     resp = await self._request_handler(request)
2019-01-03T00:53:13.357765828Z   File "/home/site/wwwroot/antenv/lib/python3.7/site-packages/aiohttp/web_app.py", line 366, in _handle
2019-01-03T00:53:13.357769728Z     resp = await handler(request)
2019-01-03T00:53:13.357773428Z   File "/home/site/wwwroot/pvscbot/__main__.py", line 39, in main
2019-01-03T00:53:13.357785827Z     logging.exception()
2019-01-03T00:53:13.357790027Z TypeError: exception() missing 1 required positional argument: 'msg'

Document how to deploy

When a PR is opened against an issue, change the issue to 'in progress'

Write a data-science-skipping decorator

Easier than special-casing everywhere.