Check spelling updates #47
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ideally check-spelling would happily handle PRs made from before check-spelling was merged, but as of 0.0.21, it has a bug where it doesn't do quite the right thing. The `check-spelling/spell-check-this@prerelease` configuration currently has a workaround where it includes a 🚂 to suggest to users to rebase to a point where the configuration is live. I believe I've properly fixed the underlying bug in `check-spelling/checkout-merge@prerelease`, but I need to test it for a while before I release it, and all the features that are currently in `check-spelling/check-spelling@prerelease` also need testing before it'd be available in a `check-spelling/[email protected]`. In the interim, there's a fancier trick which should result in users getting the desired behavior without requiring any additional updates from check-spelling. Instead of pointing `spell_check_this` to `check-spelling/spell-check-this@prerelease` which is a default from `.github/workflows/spelling.yml` in `check-spelling/spell-check-this@prerelease`, we point to this repository's default branch (`powerdns/lightningstream@main`). The `spell_check_this` field is used by check-spelling whenever it encounters a checkout without *any* configuration in the configuration directory (by default, that's `.github/actions/spelling`). Anyone who makes a branch from this repository after check-spelling was added (0365b9d) should trigger this code path (unless they choose to delete all of the configuration, which seems unlikely). Thus, the only people who should be impacted are those who have created a branch from before that commit and then try to create a PR to some branch that includes check-spelling (and this commit). In all likelihood, they will be creating their PR against the `powerdns/lightningstream` repository and against the `main` branch. As it'd be pretty weird to be creating a PR against that repository and some other branch that also has check-spelling (instead of starting from a more recent commit in case someone wanted to make a backport). For more details about this workaround, see: https://github.com/check-spelling/check-spelling/wiki/Onboarding#v0021
Note that if a job asks for write permissions and an organization's defaults are for read, then the grant for that specific permission is obviously larger than the organization's default, but, unless a job asks for all possible permissions, it will still have a narrower range than a job that does not specify permissions, as any permission not listed will not be granted.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is a bundle of fairly unrelated things.
Note that the commit messages for some of these changes are incredibly long.
The
m_datacomment update corresponds to this:check-spelling/spell-check-this@4f81233
@Habbie asked me if I knew where it came from, and at the time it was written, I didn't, it was just something that was mentioned by https://github.com/nasa/fprime as a thing they'd like to be able to handle (nasa/fprime#855). It turns out their repository actually did indicate which vendor had the issue (nasa/fprime@aa4cb00), but I didn't check for that and merely noted it as a theoretical case. I've now updated the check-spelling wiki entry to provide more information about its pedigree.
The expect updates would be triggered the next time someone introduced a misspelling, but since I'm already making a PR, I'm bundling it here. (They're mostly the result of #44's changes which excluded checking the
.github/workflowsdirectory.) Fwiw, this is a conscious tradeoff. check-spelling aims for a form of "eventual consistency". It's more or less ok to temporarily have a couple of stray expected items as they'll be cleaned up the next time someone tries to add an unexpected word. If there's ever a case where you really don't want a word coming in, you can use the forbidden feature (asm_datacould be -- see above).