-
Notifications
You must be signed in to change notification settings - Fork 241
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
fix(Amazon Q): fix for test generation target file missing from payload. #5261
Conversation
… and fix for /test query for non-supported languages.
/retryBuilds |
@@ -218,9 +206,39 @@ class FeatureDevSessionContext(val project: Project, val maxProjectSizeBytes: Lo | |||
|
|||
// gitignore patterns are not regex, method update needed. | |||
private fun convertGitIgnorePatternToRegex(pattern: String): String = pattern | |||
// Escape special regex characters except * and ? |
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.
tests?
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.
will add
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.
Added tests
@Test | ||
fun `test pattern ending with slash`() { | ||
val input = "build/" | ||
val expected = "(?:^|.*/?)build/.*" |
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.
these patterns have polynomial complexity. should there be a filter on input to prevent DoS of user's machine?
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.
also can we investigate what it would look like to use the same glob logic that git uses to match files? seems like that might be simpler than trying to build these patterns
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.
Added checks for polynomial complexity and makes sense for glob logic. will take a look into it. Wanted to drop regex matching entirely for /test. Only reason still being used is to restrict payload size which is leading to payload size errors.
/retryBuilds |
@Test | ||
fun `test basic pattern conversion`() { | ||
val input = "*.txt" | ||
val expected = "(?:^|.*/?)[^/]*[^/]\\.txt(?:/.*)?\$" |
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.
How do I validate if this is correct?
This appears to be a snapshot test of what is built versus a functional test that demonstrates that what is an example file that would've been dropped is no longer dropped
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.
we can test for pattern matching as well. That's why i included more files in the project zip test to validate it. Including false positives.
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.
My point is that these tests do little to validate behaviors and protect against regressions. If we need to update the logic, how does one go about constructing the expected value?
Regardless, outside of the zip test above, I'd like to see more examples of each of these type of files and how they respond to the presence of such inputs in the gitignore.
"(?:^|.*/?)$result" | ||
} | ||
|
||
// Handle end of pattern |
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.
What is this doing? How do I know if the behavior is comprehensive?
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.
to handle folder structures in patterns. for /src
and src/
cases
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.
Its too match all contents inside the directory in case of src/
and glob matching to check for .svg
and .png
and other patterns everywhere and not just in root.
fun convertGitIgnorePatternToRegex(pattern: String): String? { | ||
// Skip invalid patterns for length check | ||
if (pattern.length > MAX_PATTERN_LENGTH) { | ||
return null |
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.
What happens when this returns null? Why was this value decided to be 256?
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.
256 is generally placed limit. If it returns null , nothing happens pattern matching skips incase of null.
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.
Is a different way of saying this that if the pattern is longer than 256 characters, then we will make no effort to exclude it and will always include it in the zip?
/retryBuilds |
@@ -102,11 +117,73 @@ class FeatureDevSessionContextTest : FeatureDevTestBase(HeavyJavaCodeInsightTest | |||
"gradlew", | |||
"gradlew.bat", | |||
"README.md", | |||
"settings.gradle", |
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.
Just noticed that settings.gradle
and build.gradle
are being dropped. These should be included as a part of the zip for /dev.
Is this the result of changing the gitignore used for the test or a change in the actual behavior of the function?
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.
Can amend this for /dev.
@Test | ||
fun `test basic pattern conversion`() { | ||
val input = "*.txt" | ||
val expected = "(?:^|.*/?)[^/]*[^/]\\.txt(?:/.*)?\$" |
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.
My point is that these tests do little to validate behaviors and protect against regressions. If we need to update the logic, how does one go about constructing the expected value?
Regardless, outside of the zip test above, I'd like to see more examples of each of these type of files and how they respond to the presence of such inputs in the gitignore.
fun convertGitIgnorePatternToRegex(pattern: String): String? { | ||
// Skip invalid patterns for length check | ||
if (pattern.length > MAX_PATTERN_LENGTH) { | ||
return null |
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.
Is a different way of saying this that if the pattern is longer than 256 characters, then we will make no effort to exclude it and will always include it in the zip?
#5261 (comment) |
#5261 (comment) |
… and fix for /test query for non-supported languages.
Types of changes
Description
Target File was getting filtered out due to featureDevSession Regex pattern matching based filtering. For example, a folder called
builder
is getting filtered out and the files in it because regex pattern includebuild
.build
to filter outbuild
build/
build/something
path/to/build
path/to/build/
path/to/build/something
and not filter out
/builder/
Checklist
License
I confirm that my contribution is made under the terms of the Apache 2.0 license.