Conditional substitution?

[daobrien]

We have a substitution rule whose main goal is to identify DEI issues (e.g., use of master, slave, sanity, etc) and offer suitable suggestions. This partly works, but we want to refine it so that we can specify particular suggestions in particular cases.

E.g., for "master dns zone" we want to suggest "primary", and not any of the other alternatives to "master" that are otherwise on offer. I've tried working with lookaheads but so far haven't been able to make it work. Right now the main part of the style looks like this:

extends: substitution
message: "Consider '%s' instead of '%s'.
link: 'https://stylepedia.net/style/6.0/#inclusive-language'
level: warning
ignorecase: true
action:
  name: replace
swap:
  - master(?! dns| zone): main|primary|controller|leader
  - slave: worker|child|helper|replica|secondary
  - black[ \-]?list: denylist|blocklist
  - white[ \-]?list: allowlist
  - sanity check: smoke test

The other issue that we're having is that if a piece of text triggers two rules, then it seems to do so inconsistently. If we run it once it might fail on one rule, and if we then run it again it might fail on a different rule. I haven't found a pattern to this.

Greatly appreciate any help.

[jdkato]

This will work:

extends: substitution
message: "Consider '%s' instead of '%s'."
link: "https://stylepedia.net/style/6.0/#inclusive-language"
level: warning
ignorecase: true
action:
  name: replace
swap:
  - master(?! dns zone): main|primary|controller|leader
  - master dns zone: primary

which gives

 cases/test2.md
 3:1  warning  Consider 'main', 'primary',     Test.Rule 
               'controller', or 'leader'                 
               instead of 'master'.                      
 5:1  warning  Consider 'primary' instead of   Test.Rule 
               'master dns zone'.

[daobrien]

I totally missed this and haven't tested it, but it's now on my list. Thanks a lot.

[daobrien]

I'm curious to know what your test file is for this. I have these two styles set up:
inclusive.yml

  - master(?! dns server): main|primary|controller
  - slave(?! dns server): secondary|child|helper|replica
  - master(?! dns zone): main|primary|controller
  - slave(?! dns zone): secondary|child|helper|replica

and master-slave.yml

  - master dns zone: primary dns zone
  - master dns server: primary dns server
  - master zone: primary zone
  - master server: primary server
  - slave dns zone: secondary dns zone
  - slave dns server: secondary dns server
  - slave zone: secondary zone
  - slave server: secondary server

The rest of the rule definition is the same as the original.
I'm testing on only the following two statements for now:

Install the master dns server
Reconfigure the master dns zone

Results:

/home/david/testing/hack-test.adoc
 1:13  warning  Consider 'main', 'primary', or 'controller' instead of 'master'.  rht.inclusive    
 1:13  warning  Consider 'primary dns server' instead of 'master dns server'. rht.master-slave 
 3:17  warning  Consider 'main', 'primary', or 'controller' instead of 'master'. rht.inclusive    
 3:17  warning  Consider 'primary dns zone' instead of 'master dns zone'. rht.master-slave 

As you can see, both rules are being triggered. By rights, rht.inclusive should not trigger at all. Did I miss something?

Thanks

[jdkato]

Your Inclusive.yml file doesn't make sense:

  - master(?! dns server): main|primary|controller
  - master(?! dns zone): main|primary|controller

One of these cases is always going to match (if one doesn't, the other will). I think you want something like master(?! dns (?:server|zone)).

[daobrien]

Maybe I can't read the expressions properly? I read that as "master not followed by ' dns server'" (and likewise for "zone") but maybe that's not how it works.

master(?! dns zone) is a straight copy/paste from your original solution and I created master(?! dns server) from that.

Testing with your updated suggestion...

[jdkato]

They make sense in isolation, but together they are contradictory:

"master not followed by ' dns server'" will match against "dns zone".

[daobrien]

I was unable to make this work. Perhaps it's because we have other tests for master and slave in the same style? I eventually created a separate rule to handle these use cases, and it seems to be working. Still testing.

[daobrien]

We ended up resolving this by having two rules. I think we just had too many variations to make it all work reliably in one rule. Thanks for all the tips 👍