-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add codemod ID #35
Add codemod ID #35
Conversation
codetf.md
Outdated
|
||
Each component of the ID has a particular meaning: | ||
|
||
* `<origin>`: Origin describes the source of the analysis or transformation. For example, "find and fix" codemods provided by Pixee are labelled with the origin "pixee". Codemods that remediate issues found by a static analysis tool might be labelled with the origin corresponding to that tool name (e.g. "semgrep" or "codeql"). Implementers of custom codemods may use a unique identifier that is specific to their organization or tool. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Origin describes the source of the analysis or transformation
I feel like it should always be the source of the analysis and never the transformation.
Let's consider the custom codemod use case. If a user develops a custom Sonar codemod and wants to use it with our platform, the origin better be "sonar", or our platform will not consider it to be a Sonar codemod that gets access to Sonar results.
If you agree, then can we rename this to scanner()
? I have come across places in our platform where we actually translate "origin" to "scanner", and I think the latter makes more sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like scanner
because there's no reason codemodder couldn't take input from non-scanner sources of code information, like observability tools, IAST, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
detector
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like detector
. This fits with the way we talk about it in codemodder architecture.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love it when we use the same words everywhere 😊
codetf.md
Outdated
|
||
Each component of the ID has a particular meaning: | ||
|
||
* `<origin>`: Origin describes the source of the analysis or transformation. For example, "find and fix" codemods provided by Pixee are labelled with the origin "pixee". Codemods that remediate issues found by a static analysis tool might be labelled with the origin corresponding to that tool name (e.g. "semgrep" or "codeql"). Implementers of custom codemods may use a unique identifier that is specific to their organization or tool. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Codemods that remediate issues found by a static analysis tool
Our docs use the term fix only codemods, but I don't think that has stuck.
I've left some wiggle room in the description of the "origin" component, but we may want to draw a harder line.