Add check-spelling

[jsoref]

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).

Fixes #2223

Description
Add check-spelling workflow based on spell-check-this: spelling.yml and jsoref@0029254#diff-aa48ce5bca2bfbf528400261b9c5a206f60410e880f71a80499efbe87ea236b2

Alternative(s) considered
Have you considered any alternatives?
There are other tools, I've found them to not be as good as mine.

And if so, why have you chosen the approach in this PR?
@jingtang10 invited me to do this in #2193 (review)

Type
Choose one: Code health

Screenshots (if applicable)

Checklist

• I have read and acknowledged the Code of conduct.
• I have read the Contributing page.
• I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
• I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
• I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
• I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
• I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

---

check-spelling is configurable

• the readme that is included in this PR is purely to help people who examine the configuration data -- it can be omitted.
• the particulars of a footer to the report (advice.md and microsoft/terminal's implementation for some examples) that's appended at the end of reports when the tool finds problems -- this can be tweaked at any time in that file.

The main choices are:

• report a ❌ status for the check (I generally do this, but one project opted out of this) -- this is configurable in the workflow file
• include a comment in the PR (I used to do this by default, but have mostly switched to relying on github status reports instead -- enabling the comment means giving the workflow pull-requests: write which people don't really like, and I agree) -- this is configurable in the workflow file
• any particular files to exclude (excludes.txt) -- this file (or a split of it) can be tweaked at any time.
• sarif can be turned off, but the integration is pretty nifty

Upgrading from one version to the next should usually work reasonably well, however at the present time if you (but not dependabot) make a change to the workflow file itself, those changes will only be tested if you create a push (without a pull request in the same repository) and not when you create a pull_request -- this was an optimization because getting conflicting output between a push and a pull_request seemed confusing and what matters in general is the result of the merge as opposed to the result of a push.

You can play around with this code in https://github.com/check-spelling-sandbox/android-fhir/

[vorburger]

This looks "scary", to me. I noticed the related comments on top, and (I admit only very very briefly) glanced over https://github.com/check-spelling/check-spelling/wiki/Feature:-Sarif-output ... I don't really know what "SARIF support for code scanning" does - perhaps you would like to elaborate "automatically generate shiny annotations" on your Wiki, maybe e.g. with a screenshot illustrating it? But even then... doesn't this, in theory (I'm sure you're trustworthy, but this is more about principle), allow the action, if it were to become malicious, to overwrite "security events"? Unless we can reassured that this is fairly harmless, personally I would be more inclined to accept merging this PR without this particular bit?

[jsoref]

Yeah, it scares me too, I really wish the api had an explicit "append only" flavor. The specific apis that this allows are:
https://docs.github.com/en/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts

I believe that technically this is using https://docs.github.com/en/rest/code-scanning/code-scanning?apiVersion=2022-11-28#upload-an-analysis-as-sarif-data -- the code I'm using is https://github.com/github/codeql-action/blob/main/upload-sarif/action.yml -- but sadly just because that's what I'm trying to use doesn't mean that the workflow couldn't access one of the other apis if there's an exploit.

From a risk analysis perspective, it appears that there are two other write enabled apis that I'd be concerned about if I heavily used sarif:

• Update a code scanning alert
• Delete a code scanning analysis from a repository

fwiw, you're using the same feature here:

android-fhir/.github/workflows/codeql.yaml

Line 20 in a71109b

security-events: write

What that means is that either of these two workflows could probably update or delete the items produced any of these security-events: write workflows.

I've updated that page to include pictures (they're elsewhere in the wiki, but it makes a lot of sense to include them here, thanks for calling that out!).

I'm quite happy to drop this feature for this repository, it's still new and it's definitely optional -- I can't use it for our commercial work because it requires paying for GHES & GHAS for private repositories, so check-spelling definitely works without it.

I believe I'm trustworthy, but I, like most devs make mistakes and have made mistakes, so being conservative is absolutely reasonable. I'll drop this feature from the PR.

[omarismail94]

Im closing this for now. We're not ready to give write permissions to the action

[jsoref]

@omarismail94: it's optional, I can configure it without that if you're interested.