Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Allow customizing semgrep configurations; correct rule matching glob #21126
Allow customizing semgrep configurations; correct rule matching glob #21126
Changes from 2 commits
f092630
c55500a
24b5d51
bb4842c
1e1a899
71e477a
c9e985f
3e47476
8f38d51
582cf7b
e3a961c
ed06049
7579179
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 this new approach a lot more! Thanks.
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.
Ah... sorry about forcing you to re-investigate everything about these ignore files. This was known in the original addition of the backend, and cut out of scope: #18593 (comment)
I even referenced huonw#1 "so I don't forget about it", but look how far that's gone. 🙈
In any case, I think these two things are true, and still true as of this PR:
semgrep
in the sandbox root (i.e. working directory is the root of the repository).semgrepignore
in its working directoryGiven this, running semgrep via pants will only ever successfully read
//.semgrepignore
. Thus, someone who setsignore_config_path = "some/sub/directory/.semgrepignore
will just have semgrep not using the ignore. It'll be included in the sandbox, but not used!(The thinking behind the globbing behaviour was "future proofing": if a new version of semgrep started reading the nested
.semgrepignore
s, it'll automatically work with Pants, because Pants is including them in the sandboxes.)Two questions:
.semgrepignore
) because it was causing problems? Can you be specific about what the problems are?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.
Ah gotcha, I'm on my phone right now but I'll look at those PRs later.
No, it wasn't causing problems. Basically when I was adding the description for the semgrepignore customization, I initially had a note that it was hierarchical. That got me curious, so I tried to use it, and realized it did not work as expected. Probably should've done a git blame to see why it was done, but I decided to mention explicitly that it had to be at the root-based path (since this is different from the rules dir behavior), and remove the relevant code.
Shall I add it back with a note about context? Though I do think as it stands pants taking this on will be a huge burden in taking over tool responsibility stuff. The simplest way I can think to get it done would be to to inject
:include
s into the root semgrepignore during the pants run. Is there any precedent to alter file digests like that?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.
And yeah, just realized semgrepignore is not actually customizable, so should just remove this and go back to the hard-coded value.
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.
😂 hilarious that we ended up with nearly the same integration tests for showing this behavior
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.
removed this configurability
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.
Yes, I agree that Pants should try to avoid having too much "smarts" tailored to each tool.
My thinking with the continuing work related to
.semgrepignore
(i.e. huonw#1) was just to make it more obvious when something is ignored, to reduce confusion. Not "invent" a new file.