Configure pre-commit CI (#16866)

Part of #10516

Summary of the issue:
As a developer, I would like automation tools to fix the lint of my code when I open a PR.
After #16936, we have applied pre-commit on all files. However, there are no automation checks for some of these checks (like whitespaces changes). Which means without running pre-commit automatically, the repository may have pre-commit regressions.

Description of user facing changes
Improved documentation for pre-commit hooks and the PR contribution process.

Description of development approach
Setup Pre-commit CI. This is a CI/CD tool to automatically apply pre-commit to PRs.

.pre-commit-config.yaml

@@ -1,12 +1,24 @@
 exclude: ^user_docs/(?!en/).*$
 
+# https://pre-commit.ci/
+# Configuration for Continuous Integration service
+ci:
+  # Can't run Windows scripts on Linux
+  # These also do not apply fixes, only run tests
+  skip: [scons-source, checkPot, unitTest, licenseCheck]
+  submodules: true
+  autoupdate_commit_msg: "Pre-commit autoupdate"
+  autofix_commit_msg: "Pre-commit autofix"
+
 repos:
 
 - repo: https://github.com/pre-commit/pre-commit-hooks
   rev: v4.6.0
   hooks:
     # Checks python syntax
     - id: check-ast
+      # File uses encoding not supported in Linux
+      exclude: source/comInterfaces/_944DE083_8FB8_45CF_BCB7_C477ACB2F897_0_1_0.py
     - id: check-case-conflict
     - id: check-merge-conflict
     - id: trailing-whitespace

projectDocs/dev/contributing.md

@@ -42,18 +42,30 @@ If you are new to the project, or looking for some way to help take a look at:
 	- Run `scons checkPot` to ensure translatable strings have comments for the translators
 	- Run `runlicensecheck.bat` to check that you don't introduce any new python dependencies with incompatible licenses.
 1. [Create a change log entry](#change-log-entry)
-1. [Create a Pull Request (PR)](./githubPullRequestTemplateExplanationAndExamples.md)
-	- When you think a contribution is ready, or you would like feedback, open a draft pull request.
-	When you would like a review, mark the PR as "ready for review".
-	- Please fill out the Pull Request template, including the checklist of considerations.
-	The checklist asks you to confirm that you have thought about each of the items, if any of the items are missing it is helpful to explain elsewhere in the PR why it has been left out.
-	- Automated checks will be run against your PR.
-	If these fail, please review them.
-	Sometimes system tests fail unexpectedly.
-	If you believe the failure is unrelated, feel free to ignore it unless it is raised by a reviewer.
-	- All pull requests submitted must have their "Allow edits from maintainers" checkbox ticked.
-	This is the GitHub default for new pull requests.
-	- A lead developer may specifically request the pull request be made against `beta` or `rc` in the case of addressing bugs introduced in the current release cycle.
+1. Create a Pull Request (PR)
+	1. Filling out the template:
+		- [Template guide](./githubPullRequestTemplateExplanationAndExamples.md)
+		- Please fill out the Pull Request template, including the checklist of considerations.
+		The checklist asks you to confirm that you have thought about each of the items, if any of the items are missing it is helpful to explain elsewhere in the PR why it has been left out.
+	1. Submission process:
+		- If you would like to publish unfinished work to seek early feedback or demonstrate an approach, open a draft pull request.
+		When you would like a code review or response from NV Access, mark the PR as "ready for review".
+		- All pull requests submitted must have their "Allow edits from maintainers" checkbox ticked.
+		This is the GitHub default for new pull requests, except for organisation forks.
+		Organisation forks must invite NV Access developers to collaborate directly.
+		- Consider if the PR should be made against `beta` or `rc` in the case of addressing bugs introduced in the current release cycle.
+	1. CI/CD testing:
+		- Every time a PR has a commit pushed to it, CI/CD checks will be run
+		- [pre-commit.ci](https://pre-commit.ci/) will apply linting fixes.
+			- re-run pre-commit on a pull request by commenting `pre-commit.ci run`.
+			- prevent pre-commit from pushing by putting `[skip ci]`, `[ci skip]`, `[skip pre-commit.ci]`, or `[pre-commit.ci skip]` in the commit message.
+		- AppVeyor will build a copy of NVDA when changes are pushed to your PR.
+		A build artifact will be created for a successful build to allow for testing the PR.
+		- AppVeyor will run system tests and other tests.
+		If these fail, please review them.
+		Sometimes system tests fail unexpectedly.
+		If you believe the failure is unrelated, feel free to ignore it unless it is raised by a reviewer.
+		- Security checks will be run.
 1. Participate in the code review process
 	- This process requires core NVDA developers to understand the intent of the change, read the code changes, asking questions or suggesting changes.
 	Please participate in this process, answering questions, and discussing the changes.

projectDocs/testing/automated.md

@@ -8,7 +8,7 @@ These tests help to ensure that code changes do not unintentionally break functi
 [Pre-commit hooks](https://pre-commit.com/) can be used to automatically run linting, translatable string checks and unit tests on files staged for commit.
 This will automatically apply lint fixes where possible, and will cancel the commit on lint issues and other test failures.
 
-From a shell, set up pre-commit scripts for your NVDA python environment:
+From a shell, [set up pre-commit scripts](https://pre-commit.com/#pre-commit-install) for your NVDA python environment:
 
 1. `venvUtils\ensureAndActivate.bat`
 1. `pre-commit install`
@@ -21,6 +21,14 @@ Alternatively, set up pre-commit scripts globally:
 To skip pre-commit hooks from triggering, use the `--no-verify` CLI option.
 Example: `git commit -m "message" --no-verify`.
 
+#### Manually running pre-commit hooks
+
+You can run pre-commit hooks manually with [`pre commit run`](https://pre-commit.com/#pre-commit-run).
+
+- You can filter files with `--files` and `--all-files`
+- You can also compare two revisions:
+`pre-commit run --from-ref origin/master --to-ref HEAD`
+
 ### Translatable string checks
 
 To run the translatable string checks (which check that all translatable strings have translator comments), run:

readme.md

@@ -25,3 +25,11 @@ Their contribution helps us maintain the security and integrity of our releases.
 ## Contributing to NVDA
 If you would like to contribute to NVDA, you can read more information in our [contributing guide](./.github/CONTRIBUTING.md).
 This includes information on reporting issues, triaging issues, testing, translating, contributing code/documentation and creating add-ons.
+
+## Status checks
+
+* AppVeyor
+   * Alpha build status: [![view latest alpha builds](https://ci.appveyor.com/api/projects/status/sqeer6p8lc80lvqe/branch/master?svg=true)](https://ci.appveyor.com/project/NVAccess/nvda/branch/master)
+   * Beta build status: [![view latest beta builds](https://ci.appveyor.com/api/projects/status/sqeer6p8lc80lvqe/branch/beta?svg=true)](https://ci.appveyor.com/project/NVAccess/nvda/branch/beta)
+* Pre-commit status (master): [![view pre-commit checks on master](https://results.pre-commit.ci/badge/github/nvaccess/nvda/master.svg)](https://results.pre-commit.ci/latest/github/nvaccess/nvda/master)
+* CodeQL security analysis status (master): [![view CodeQL security analysis checks on master](https://github.com/nvaccess/nvda/actions/workflows/github-code-scanning/codeql/badge.svg?branch=master)](https://github.com/nvaccess/nvda/actions/workflows/github-code-scanning/codeql?query=branch%3Amaster)

source/speech/commands.py

@@ -80,7 +80,7 @@ def _getFormattedDevInfo(self):
 	def __repr__(self):
 		return (
 			f"CancellableSpeech ("
-			f"{ 'cancelled' if self._checkIfCancelled() else 'still valid' }"
+			f"{ 'cancelled' if self._checkIfCancelled() else 'still valid'}"
 			f"{self._getFormattedDevInfo()}"
 			f")"
 		)