Adds per codemod Includes/Excludes #438
Conversation
* Reverted changes for includes/excludes in sarif files
| @@ -26,6 +26,29 @@ final class WebGoat822Test extends GitRepositoryTest { | |||
| super("https://github.com/WebGoat/WebGoat", "main", "e75cfbeb110e3d3a2ca3c8fee2754992d89c419d"); | |||
| } | |||
|
|
|||
| private static final String testPathIncludes = | |||
There was a problem hiding this comment.
Can we expose the actual values so both the tests and the CLI use the same values?
There was a problem hiding this comment.
CLI doesn't use these default includes anymore.
Do you still want these to be the default values for find-and-fix codemods? Right now every javaparser based one will only have **.java as its pattern.
core-codemods/src/main/java/io/codemodder/codemods/VerbTamperingCodemod.java
Outdated
Show resolved
Hide resolved
| @@ -29,6 +30,17 @@ protected CompositeJavaParserChanger(final JavaParserChanger... changers) { | |||
| this.changers = Arrays.asList(Objects.requireNonNull(changers)); | |||
| } | |||
|
|
|||
| @Override | |||
| public IncludesExcludesPattern getIncludesExcludesPattern() { | |||
There was a problem hiding this comment.
This doesn't seem right, but not sure I have another proposal right now.
There was a problem hiding this comment.
Ideally this would be an intersection of all the patterns. But I'm not sure we can calculate this with just the patterns themselves.
framework/codemodder-base/src/main/java/io/codemodder/IncludesExcludesPattern.java
Show resolved
Hide resolved
framework/codemodder-base/src/main/java/io/codemodder/IncludesExcludesPattern.java
Outdated
Show resolved
Hide resolved
| @@ -153,6 +163,11 @@ public List<CodeTFReference> getReferences() { | |||
| public String getIndividualChangeDescription(Path filePath, CodemodChange change) { | |||
| return null; | |||
| } | |||
|
|
|||
| @Override | |||
There was a problem hiding this comment.
In the most root interface (if you wanted), you could provide a default interface method that returns true.
There was a problem hiding this comment.
To prevent all these simple implementations.
There was a problem hiding this comment.
This was deliberate. Sarif and JavaParser based changers have reasonable defaults (sarif ones will check if the file is in the results and javaparser ones will check if it's a java file).
Notice that all these are RawFileChangers. Not having a default helps to avoid creating codemods that inspects every file by mistake.
| RawFileCodemodRunner( | ||
| final RawFileChanger changer, | ||
| final Path projectDir, | ||
| final IncludesExcludes globalIncludesExcludes) { | ||
| this.changer = Objects.requireNonNull(changer); |
There was a problem hiding this comment.
This is the only thing I don't like about this. This kind of subclass checking is a code smell of an architectural problem that will be hard to diagnose and fix later when it causes a problem.
|
Codemods now have their own includes/excludes rules and a
supportsmethod.Includes/Excludes rules are specified by
PathMatcherpatterns that are relative to the repository root.Before running on a given file, codemods will now perform two checks: includes/excludes and
supports.Codemod specific Includes/excludes check can be overridden by global configuration from the command line (i.e. with
--path-includeflag).supportschecks the bare-minimum conditions that must be satisfied before the codemod attempts to run. For example,javaparser codemods will check if the file is a java file and sarif based codemods will check if there is any results for the file.
Refactored some scattered file checks in codemods into the
supportsmethod. For example, theVerbTamperingCodemodwill now check if the file is aweb.xmlfile with thesupportsmethod instead of thevisit. This has the benefit of avoiding the generation of empty codetf reports.