Allow cascading (merged) configuration

[Piedone]

To aid DRY when check-spelling is used in multiple repositories of an organization with the goal of having pieces of the configuration common and in one place, I'd like to propose the ability to cascade (merge) configuration files.

This already seems to be possible for allow.txt. However, you need to copy the excludes.txt and patterns.txt files to each consumer project, AFAIK it's not possible to use them from something like a reusable workflow but extend on top of them.

Related: #41

[jsoref]

I believe it's possible for all files, here's an example where I'm using a matrix to share stuff between a split job:
https://github.com/check-spelling/openj9/tree/spelling-c/.github/actions/spelling-runtime

You can also use the extra dictionaries field to add in additional URLs (cspell: is just an alias for a long https: URL).

I saw GitHub's announcement about organization workflows and I'll be looking into them soon...

[Piedone]

Thank you! Could you please check, @BenedekFarkas?

[BenedekFarkas]

I might be missing some detail, but basically, the primary pain point we have right now is that we have a common set of entries for patterns.txt and excludes.txt in one common place in https://github.com/Lombiq/GitHub-Actions/tree/dev/.github/actions/spelling, as well as a wrapper action/workflow for spelling that some of our other projects use.

When such a consumer project using our wrapper workflow doesn't have a .github/actions/spelling folder (assuming we didn't override the configuration folder path), then all the configuration files are taken directly from the common repo. However, even if a single configuration file is present in the consumer project (e.g., only advice.md, but such consumer projects might have their own allow/exclude entries that aren't common and only applicable there), then the common repo's configuration files aren't used at all.

Part of that can be alleviated by using the dictionary-source-prefixes and extra-dictionaries parameters, but that only works with flat dictionary files, not all configuration files (like patterns.txt and excludes.txt), as described in https://github.com/check-spelling/check-spelling/wiki/Feature:-Area-dictionaries:

You can pull in any public url that has a flat list of words.

But TIL from what you linked that the basic configuration files (allow, expect, excludes, etc.) can be folders instead, that will be useful for us.

I looked around the repo in the link above but didn't find an answer how a consumer project could use (and potentially extend) excludes.txt or patterns.txt from the common repo. Is that possible then?

[jsoref]

If you're doing your own checkout, then you can drop your common stuff into the same directory as the repository config. If you want to use symlinks, as I do in the example, you can, but it doesn't really matter. As long as you have a directory, e.g. patterns/ (and it doesn't have a sibling patterns.txt), a file that is native to the repository patterns/repository.txt and a file that your meta drops in after checkout before check-spelling runs called patterns/template.txt that's a sibling file as far as check-spelling can see will be honored with it.

Note that it's admittedly a hack, but it should work.

I'm only, as of this week, thinking about this problem (mostly because of the GitHub announcement about required organization workflows, although also somewhat because of this ticket). I'll start thinking about a fancier solution next week.

I think the laziest approach would be for me to accept a second configuration parameter for a shared configuration directory and then adjust my code to honor both. It isn't a lot of work. The only interesting edge is that I have code that accepts multiple file names for a given feature, newest name wins (this allows me to support some deprecated names) – I'm pretty sure that is your common and repository configurations don't both use the same base name (i. e. One is using a deprecated name) I'll want to only let the files from the newest name be used.

[BenedekFarkas]

Oh, I see, thanks for the explanation!

That actually made me pick up an earlier idea again: I thought about just copying pattern.txt/excludes.txt from the common configuration to the consumer project. I dropped idea though, because I didn't want to deal with potentially merging the common files with the ones specific to the consumer repository.

But! Since patterns and excludes can both be folders too, we can just copy the common files to the consumer repository (with a different/randomized name to avoid collision) into the patterns/excludes folder (and move the local ones to those folders too) before running the actual spell-checking and that's it. This way the common configuration needs to have just a few lines of PS added and consumer repositories don't need any change for this work. Thanks!