Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
1. Issue, if available:
Adds check-spelling.dev workflow (based on check-spelling/spell-check-this@prerelease) per @ellistarn #1045 (comment).
2. Description of changes:
This adds a workflow
.github/workflows/spelling.yml
with two jobs:spelling
this checks the spelling of both branches (viapush
) and pull requests (viapull_request_target
) -- it runs with limited permissions because it takes untrusted inputcomment
this runs when thespelling
job fails and has produced output for use to construct a comment -- it needswrite
permission in order to post a comment (either to the repository or the pull request)Each time it runs, it will check the spelling of the branch/pull request.
The files in the .github/actions/spelling directory control what it checks (or doesn't) and what it expects to see.
When it sees words that it doesn't recognize and doesn't expect, it will complain (in the form of a 💬 and an ❌ ). The comment should be enough to enable contributors to identify the items they've misspelled (and fix them), or files that they should exclude (and how to do that), or hint at how they could add a pattern in order to ignore pieces of lines.
In general, I'll watch a repository for at least a month in order to ensure smooth adoption. I'll always try to respond to
@
.3. Does this change impact docs?
If necessary, changes could be made to CONTRIBUTING.md#contributing via pull requests, but I don't think that's necessary. In general the workflow should be sufficiently user friendly for contributors to understand what they need to do to make it happy.
I'd encourage testing the workflow in a fork (your own, or feel free to use check-spelling/karpenter. Create commits/pull requests with typos and push them to GitHub to see how it behaves.
Note:
You will want to enable branch protection:
Otherwise you risk merging a typo and confusing other contributors when checks run for their PR.
The workflow, as configured, when run for a Pull Request checks the code as it would look if merged as opposed to simply checking the branch as it is. This is important since configuration changes (
.github/actions/spelling
) affect not just the content of the branch but any additional content that may have been added (or removed) in the destination branch.Sample output
For reference, here's a run that I generated in tuning this PR:
In this case, the items it identified are acceptable, so I added them to
expect.txt
:https://github.com/check-spelling/karpenter/compare/81486f4c63f5e4ee8a0fa653f223d1d59e687cae..a3830d6e09fe03c7ae8397ec485f1dcf95b9b831
The extra pattern addresses
r'https
which comes from some Python. It should be good enough to cover any of the various Python formats. The patterns file includes a link to a list of samples which should help if people need to write additional patterns.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.