I'd like to decommission SITE_GITHUB_TOKEN as it's a PAT that has write
access to all my `github/*` repositories. Instead, I've created a deploy
key that only has access to `github/cli.github.com`.
ssh-keygen -t ed25519 -C "gh docs push" -N "" -f ~/.ssh/gh-docs-publish
gh repo -R github/cli.github.com deploy-key add ~/.ssh/gh-docs-publish.pub
# testing:
GIT_SSH_COMMAND='ssh -i $HOME/.ssh/gh-docs-publish' git push ...
- Use AUTOMATION_TOKEN to get around "resource not available by
integration". It looks like jobs triggered from community pull
requests do not have permissions to write to our project.
- Tolerate the "project already has the associated issue" error for
staff as non-fatal.
- Do not add draft PRs to the review board
- Do not enforce that the base branch must be "trunk"
- Refuse PRs made with our "trunk" as the head
- Improve staff check to avoid hardcoding
- Improve pattern matching when suggesting to link to an issue
- Use the stock GITHUB_TOKEN
From February 2021, in order to provide feedback on pull requests, Code Scanning workflows must be configured with both `push` and `pull_request` triggers. This is because Code Scanning compares the results from a pull request against the results for the base branch to tell you only what has changed between the two.
Early in the beta period we supported displaying results on pull requests for workflows with only `push` triggers, but have discontinued support as this proved to be less robust.
See https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#scanning-pull-requests for more information on how best to configure your Code Scanning workflows.
The user input might have come in a reply already, but the maintainers
haven't gotten around to remove the stale label yet. This shouldn't
prevent someone from submitting a PR.
GitHub has some special behavior for the `help wanted` label, but not
the `help-wanted` label, so I've renamed ours.
Bonus: updated links to docs.github.com
