Reduce configuration burden

[ellistarn]

Check Spelling was recently onboarded to github.com/aws/karpenter. This a great addition, but it comes with a concern of complexity and maintainability. The PR includes 622 lines of code to enable the checker: https://github.com/aws/karpenter/pull/1057/files. Ideally it would be ~100 lines of code to onboard.

In general, I'd like to be able to onboard to check spelling w/ something as simple as:

• a wide set of defaults that don't need to be checked in and are owned by the check-spelling code
• a configurable allow list of words (to override defaults as necessary for my project)
• a configurable block list of words (to override defaults as necessary for my project)
• a simple, well defaulted GH step to both run on pull requests and add comments (included in my ci.yaml workflow)

This could potentially look like:

.github/workflows/spelling.yml
.github/workflows/spelling/allow.txt
.github/workflows/spelling/reject.txt

I'd also prefer to not include the README in my .workflows folder, and instead rely on going to https://github.com/check-spelling/check-spelling.

[jsoref]

The readme.md isn't strictly necessary and could be removed. I believe I have the same information in this repository. If there's a specific path in this repository, I'm quite happy to make adjustments.

[jsoref]

With v0.0.20, you can now onboard with a single file:
https://github.com/check-spelling/spell-check-this/blob/744c66e2140fd8acaf5388efd0db3727d010d6e9/.github/workflows/spelling.yml

With that configuration, defaults are pulled in from check-spelling/spell-check-this. It's not quite the same as not maintaining files, since it's only temporary. But, I think I could extend it so that it could pull in any files that aren't overridden, instead of only using it for bootstrapping.

I created a sample repository that uses it (you can tell it did something because otherwise the run would have complained about the .pdf file):
https://github.com/jsoref/test-starter-workflows-0/runs/7460320509?check_suite_focus=true#step:2:1

[jsoref]

Thinking more about the actions/spelling/README.md item.

If I moved the contents of:
https://github.com/check-spelling/spell-check-this/blob/main/.github/actions/spelling/README.md

Into
https://github.com/check-spelling/check-spelling/wiki
And added a column indicating the minimum (and maybe maximum for deprecated items) versions,
I could then replace the file with a link to the wiki page. That'd work well enough on average.

How does that sound?

I think for the other items, to support minimization, I'll need to think about how to handle "inherit" vs "supplement" vs "replace". Right now spell-check-this works as a backstop for when you have nothing, but once you start configuring things, you stop using it. One of the reasons for this model is that I don't want people's instances to break if I add/remove entries from the upstream. I could adjust this by letting them point to a SHA instead of a floating branch/tag, but that's at least one consideration. The other side is: if a project does choose to use a baseline but for a certain file decides it wants to replace it instead of supplementing it, how would I let them declare that?

@ricardo-dematos do you have any thoughts?

[ricardo-dematos]

Thinking more about the actions/spelling/README.md item.

If I moved the contents of: check-spelling/spell-check-this@main/.github/actions/spelling/README.md

Into check-spelling/check-spelling/wiki And added a column indicating the minimum (and maybe maximum for deprecated items) versions, I could then replace the file with a link to the wiki page. That'd work well enough on average.

How does that sound?

Sorry, but I can't understand the purpose of this... 🤔

I think for the other items, to support minimization, I'll need to think about how to handle "inherit" vs "supplement" vs "replace". Right now spell-check-this works as a backstop for when you have nothing, but once you start configuring things, you stop using it. One of the reasons for this model is that I don't want people's instances to break if I add/remove entries from the upstream. I could adjust this by letting them point to a SHA instead of a floating branch/tag, but that's at least one consideration. The other side is: if a project does choose to use a baseline but for a certain file decides it wants to replace it instead of supplementing it, how would I let them declare that?

@ricardo-dematos do you have any thoughts?

I think that check-spelling/spell-check-this should be something like valispace/actions/check-spelling, where I'm trying to achieve a common configuration to use across Valispace repos.

checkspelling/spell-check-this could be used directly in spell_check_this, thus allowing a workflow to use it as the default configuration, even if that means breaking when changing it ( versioning ? ),

uses: check-spelling/check-spelling@v0.0.21
with:
    spell_check_this: 'check-spelling/spell-check-this@v0.0.21'

or it could be used as a template repository, where each one would configure its allowed / expected words.

uses: check-spelling/check-spelling@v0.0.21
with:
    spell_check_this: 'valispace/actions/spell-check-this@master'

---

I'm struggling to define the correct config in valispace/actions/check-spelling ... 😑