Open rvansa opened 1 year ago
there is already a linter in qDup that validates the structure of the yaml definition and does further analysis (i.e. counting signals etc). you can run it with qdup -T
without executing the script, and it is run everytime the script is run.
I think there might be a couple of concerns in this issue that could be split out;
git commit-hook
- is the idea here to run the linter on a PR to validate before the changes are committed? if so, I think this is a good idea, we just need a CI workflow to execute qDup -T
. This workflow is possible now.all scripts have the parameters used declared (as comments) next to the script name
I am not clear on what the ask is here. is this in the context of ensuring that parameters required in qDup are being provided by external qDup wrappers?atm the linter fails the test if it detects issues (@willr3 please correct me if I am wrong here), we might want to be able to have different levels, e.g. ERROR/WARN/INFO etc. and having different behaviours (i.e. logging vs failure) depending on what levels of issues are discovered.
qDup has -T
--test
to run static analysis on the scripts to verify they are runnable. it is the same static analysis that qDup performs when starting a run and it checks for signal
counts, invalid observing commands (e.g. no sh
in a watch
) and other requirements.
I think rvansa wants a linter that checks coding styles like the ones that enforce white-space rules in java projects. I can see it being helpful to raise warning for script practices that make them harder to maintain.
using ${key:defaultValue}
in multiple places might be easier to maintain with a single set-state: key ${key:defaultValue}
.
I'm opposed to style rules for running scripts but I can see a value in a way to check style along with the static analysis rules.
Perhaps a way to add io.hyperfoil.tools.qdup.config.RunRule
through the globals
?
Yes, it should be part of the other static analysis.
@johnaohara
@willr3 If the static analysis provides just hints/warnings it's most likely to be ignored, there's so much of qDup output... There are two reasons (name others please) why I don't like checkstyle on commit:
A linter would be useful as git commit-hook that will ensure that:
${{<var>:<default>}}
: if the same default is used multiple times this should be extracted toset-state: <var> ${{<var>:<default>}}
ahead (or proposed #160 )