Add blacklist and whitelist to flagWords

Since preparing this issue, the Core issue has now been merges in 11.x so we should follow, as the original flagWords used in contrib pipelines was taken from the core file.

If we added a change record, it could link to the core issues, and also explain about using cspell:ignore whitelist etc in places which cannot be changed yet (there are several in that Core MR)

Do we need to give notice of this upcoming chanage, say in Slack? The default allow_failure for cpsell is true, so unless any contrib maintainer has explicitly set it to false, then the pipeline will not fail.

I have added BEFORE_SCRIPT_ACTIONS to test the downstream projects, but they failed already even without that commit.
https://git.drupalcode.org/project/gitlab_templates_downstream/-/jobs/52...

This highlights another problem I had already noted about cspell, that it is checking the contents of build.env when I do not think it should. The maintainer does not have control over what goes in to this file, and things like branch names and references are written which fail spelling. This confuses the log, and obscures the real spelling errors.

In this case, the job failed because that branch did not have its own .cspell.json so was taking the file from Core. The changes in this MR are needed when a project has its own .cspel.json which probably may not contain all the core flagWords.

From the core issue (comment #7):

It looks like chromedriver have deprecated --whitelisted-ips and replaced it with --allowed-ips, let's see if this works.

We should do this here too I guess.

--

Re change record: yes, let's do it and link to the core issue. As you say, the default is to allow failure, so the overall pipeline result shouldn't be affected. I can make a quick slack post once we merge it, pointing at the change record.

--

Re build.env, yes, it should be ignored in the cspell job.

NW for the chromedriver args. The rest looks good.

Before we change --whitelisted-ips in main.yml and main-d7.yml I would like to know why those did not fail the internal cspell job? We use the same scripts/prepare-cspell.php for our own checking, don't we?

Unintended change, sorry. New comments arrive, but the form values remain unchanged, so when I reply it makes the change back to the old value.

Not in this case:
- (Contrib) https://git.drupalcode.org/project/gitlab_templates/-/blob/main/assets/....
- (Internal) https://git.drupalcode.org/project/gitlab_templates/-/blob/main/assets/i...

We'll need to add them to the internal one too.

Of course. I was thinking that we merged the values from the contrib default if they were not in the internal file. But we don't do that. We could I suppose. But the simple solution is to just put them in both files. I'll do that for all the flagWords.

Adding the blacklist and whitelist words to /internal/.cspell.json made the 'check code' job fail as intended.
https://git.drupalcode.org/issue/gitlab_templates-3524087/-/jobs/5240491
I also re-ordered a couple of items in the file to make them the same as the default, for easier comparing.

Now that we have all the other flagWords, I had to add <!--- cspell:ignore grey queuing --> into the cspell.md file which is fine. But interestingly the word 'e-mail' was not reported as a flagged word. Probably the hyphen is treated as a word-break? Maybe this does not work in Core either?

I have added GTD before_script_action to all the D9 and D10+ branches to used flagged words. The jobs all fail as required. Here is one example
https://git.drupalcode.org/project/gitlab_templates_downstream/-/jobs/52...

Interesting that we get suggestions of the plural forms of the words:

spelling-test.md:1:23      - Forbidden word (blacklisted) -- Now we are using some blacklisted whitelist words.
  Suggestions: [blacklists, blacklist's, backlist, backlists, blocklist]

spelling-test.md:1:35      - Forbidden word (whitelist)   -- using some blacklisted whitelist words.
  Suggestions: [whitelists, whitest, whitefish, whiteouts, whitebaits]

So I think we should add those forms too, then feed back to the c ore issue to add them also. There is no point in have 'blacklist' as a flagged word if we allow 'blacklists'

Maybe we can add the suggestions (eg: whitelist->allowlist). https://cspell.org/docs/api/cspell-types/interfaces/Settings#flagwords
That way it will not recommend derivatives of the words.

That's even better. I have tested this locally, and found out that suggestions are only given when the specific word is supplied with a suggestion, you don't get derivative-created suggestions. I've pushed the changes and here's the test.

However, I have found that even though 'blocklist' is a known word, 'blocklists' and 'blocklisted' are not recognised.

spelling-test.md:2:40      - Unknown word (blocklisted) -- of whitelists and the blocklisted denylist allowlists
	 Suggestions: [blocklist, blockList, BlockList, blocklint, blacklist's]

So maybe we should not be adding those as suggestions, just 'blocklist' and all the 'denylist' variations.

Now we do not get suggestions for 'blocklisted'
https://git.drupalcode.org/project/gitlab_templates_downstream/-/jobs/52...

This is ready for review and feedback. Is it possible to verify the chromdriver change?

-    - '--whitelisted-ips='
+    - '--allowed-ips='

Or do we just assume that because that is what was changed in core then it's correct here too?

Testing any pipeline that uses the legacy driver should be good enough, or any D7 pipeline.
I think the change should be pretty safe because it actually happened a few years ago https://github.com/SeleniumHQ/selenium/pull/11409 upstream.

I think that, other than the @todo, everything looks good. RTBC (pending the removal of the todo).

Our GTD d9 branch uses the legacy driver, and those javascript tests passed, so that seems OK.
I've removed the temporary test lines.
NW because we were we going to create a Change Record