- The certificate pfx file is now read from WINDOWS_CERT_PFX
- The password to decode the pfx is in WINDOWS_CERT_PASSWORD
- Quit reading from desktop-secrets repo
- Switch osslsigncode to take in pfx instead of individual certs
- 🔥 obsolete setup scripts
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 ...
Resolves#703 along with several other issues:
* Build an x64 MSI for an x64 executable. This means the binary is installed to C:\Program Files, by default, rather than C:\Program Files (x86) without the ability to redirect it to 64-bit locations.
* Environment change to PATH is not system-wide, which for a per-machine install it should be so all users who can access the executable have it in their PATH.
* Environment change to PATH is not cleaned up when uninstalled.
* RTF conversion of LICENSE was difficult to read. A simple conversion script is checked in to facilitate regenerating RTF from root LICENSE.
- 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.
