Revert "[SCB-Bot] Upgraded semgrep from 0.84.0 to 0.85.0"#1044
Merged
malexmave merged 1 commit intoMar 17, 2022
Conversation
Weltraumschaf
approved these changes
Mar 17, 2022
|
I wonder if you can add a |
Member
Author
|
Good idea with the excludes. I just tested it, and it's a viable workaround. I will implement it once our bot has created a new pull request with the upgrade. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
The new update for semgrep has changed how files are found - it now also considers hidden folders. This leads to the test file in the integration tests being found either twice or not at all: apparently K8s, when mounting ConfigMaps, will put the real file in a hidden folder, and then symlink to it. As there is currently an inconsistency in how symlinks are handled by semgrep, I cannot simply tell the integration test the path to the (symlink) file directly, because this will be considered as "not existing" by semgrep (see linked issue).
As I don't want to update the test case with an ugly hack (e.g., trying to wildcard my way into the hidden folder k8s uses), and don't want to update the expected number of results to two times the results we would actually expect, I'm reverting the change for now to get the CI to turn green again. When the dependency bot opens a new PR, we can find a nice way of getting the CI to pass, or wait for the next semgrep release that fixes the inconsistency in symlink handling and then merge that.