- 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 gh formula in homebrew-core went back and forth between git-style
and tarball-style. Now that it's back to tarball, update the action to
reflect that.
- deb and rpm packages are now built for prereleases
- consolidate setup for deb & rpm
- man pages are generated for prereleases
- the `cli.github.com` site is only pushed to on full releases
Bonus:
- only publish the GitHub release after the Windows MSI is uploaded
- hub does not need downloading
* We are trying to keep the binary building on Go 1.13 to support building the project on Ubuntu 20.04 LTS
* Go 1.14+ is required to run the test suite
* We build our releases on Go 1.15
This adds a CI check that verifies that the project compiles on 1.13
