When an auto-completing label is applied to a new PR before GitHub has added the Checks to it, the labeled notification our webhook gets indicates that mergeable_state="clean", so we may immediately merge the PR rather than waiting for Checks to be added and then complete.

This PR auto-merge'd before checks were complete: #26

We should specify the sha parameter when merging the pull request so that the merge will not happen if the PR head branch was pushed to more recently than the notification we're responding to.

Prerequisites to making repo public:

• #13

Similar to Azure Repos, we can add a PR comment once an auto-complete label is applied to a PR indicating what conditions (if any) prevent merging immediately. We can edit that same comment as conditions change so the status is always current.

For example, in a repo where squash is forbidden, do not create the auto-squash label when installing the app to the repo.

• Shift to obtaining secrets from Key Vault instead of app service configuration. This will allow devs to obtain secrets on their dev boxes from Key Vault as well.
• Recycle existing secrets (the webhook secret and the private key).

Keep in mind that we probably should move to GitHub App manifests soon and as such, at app creation time we should be able to store the webhook secret and private key assigned us from GitHub.

• Set up staging slot
• Create staging GitHub App that refers to staging slot
• Get CI/CD set up

We should be notified when the service becomes unresponsive or responds with non-200 errors.

On a PR targeting a branch that requires 1 approval, where the PR has already reached mergeable_state="clean", adding the auto-merge label led to a 500 error because we tried to merge the PR and it threw an error:

RequestError [HttpError]: At least 1 approving review is required by reviewers with write access.
    at /home/site/wwwroot/node_modules/@octokit/request/dist-node/index.js:66:23
    at processTicksAndRejections (internal/process/task_queues.js:97:5) {
  status: 405,
  headers: {
    'access-control-allow-origin': '*',
    'access-control-expose-headers': 'ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, Deprecation, Sunset',
    connection: 'close',
    'content-length': '165',
    'content-security-policy': "default-src 'none'",
    'content-type': 'application/json; charset=utf-8',
    date: 'Mon, 10 Aug 2020 13:27:49 GMT',
    'referrer-policy': 'origin-when-cross-origin, strict-origin-when-cross-origin',
    server: 'GitHub.com',
    status: '405 Method Not Allowed',
    'strict-transport-security': 'max-age=31536000; includeSubdomains; preload',
    vary: 'Accept-Encoding, Accept, X-Requested-With',
    'x-content-type-options': 'nosniff',
    'x-frame-options': 'deny',
    'x-github-media-type': 'github.v3; format=json',
    'x-github-request-id': 'C9C3:0A41:3DC8B63:692E58B:5F314B54',
    'x-ratelimit-limit': '15000',
    'x-ratelimit-remaining': '14998',
    'x-ratelimit-reset': '1597069668',
    'x-xss-protection': '1; mode=block'
  },
  request: {
    method: 'PUT',
    url: 'https://api.github.com/repos/microsoft/vs-streamjsonrpc/pulls/516/merge',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': 'octokit-rest.js/18.0.3 octokit-core.js/3.1.1 Node.js/12.18.0 (linux; x64)',
      authorization: 'token [REDACTED]',
      'content-type': 'application/json; charset=utf-8'
    },
    body: '{"merge_method":"merge"}',
    request: { hook: [Function: bound bound register] }
  },
  documentation_url: 'https://docs.github.com/articles/about-protected-branches'
}

We should either detect that the merge would not be successful and avoid trying, or we should catch the error and still return 200 to the GitHub event that called us.

When the app is installed to a repo, it should automatically define the supported labels within the repo.

https://docs.github.com/en/developers/apps/using-the-github-api-in-your-app#step-3-create-a-new-label

In this PR the head branch was not deleted when the PR was completed, even though the repo settings indicated it should be. Is this setting ignored when a bot completes a PR? If so, we should have our bot manually honor it by deleting the head branch.