But, if you really want to exclude this test specifically, you can also add it to your excluded tests temporarily:
diff --git a/pkl-core/src/test/kotlin/org/pkl/core/LanguageSnippetTestsEngine.kt b/pkl-core/src/test/kotlin/org/pkl/core/LanguageSnippetTestsEngine.kt
index 1aca859ab..061ecf81c 100644
--- a/pkl-core/src/test/kotlin/org/pkl/core/LanguageSnippetTestsEngine.kt
+++ b/pkl-core/src/test/kotlin/org/pkl/core/LanguageSnippetTestsEngine.kt
@@ -58,6 +58,7 @@ abstract class AbstractLanguageSnippetTestsEngine : InputOutputTestEngine() {
override val excludedTests: List<Regex> = buildList {
add(Regex(".*/native/.*"))
+ add(Regex(".*/invalidGlobImport6\\.pkl"))
if (IoUtils.isWindows()) {
addAll(windowsExcludedTests)
}
@bioball commented on GitHub (Oct 15, 2024):
Typically, I only include the tests that address the issue I'm working on by adding a filter here: https://github.com/apple/pkl/blob/d00c466843abf1d88abf9d897941fce71334efd4/pkl-core/src/test/kotlin/org/pkl/core/LanguageSnippetTestsEngine.kt#L53
But, if you really want to exclude this test specifically, you can also add it to your excluded tests temporarily:
```diff
diff --git a/pkl-core/src/test/kotlin/org/pkl/core/LanguageSnippetTestsEngine.kt b/pkl-core/src/test/kotlin/org/pkl/core/LanguageSnippetTestsEngine.kt
index 1aca859ab..061ecf81c 100644
--- a/pkl-core/src/test/kotlin/org/pkl/core/LanguageSnippetTestsEngine.kt
+++ b/pkl-core/src/test/kotlin/org/pkl/core/LanguageSnippetTestsEngine.kt
@@ -58,6 +58,7 @@ abstract class AbstractLanguageSnippetTestsEngine : InputOutputTestEngine() {
override val excludedTests: List<Regex> = buildList {
add(Regex(".*/native/.*"))
+ add(Regex(".*/invalidGlobImport6\\.pkl"))
if (IoUtils.isWindows()) {
addAll(windowsExcludedTests)
}
```
My point is that this test slows down ./gradlew test by 15 seconds, which isn't justified.
A common solution for testing the enforcement of a limit is to make the limit configurable and set a lower limit for the test.
@odenix commented on GitHub (Oct 15, 2024):
My point is that this test slows down `./gradlew test` by 15 seconds, which isn't justified.
A common solution for testing the enforcement of a limit is to make the limit configurable and set a lower limit for the test.
Would you be OK with making this limit configurable in the CLI and Evaluator API?
PS: Is a Pkl release imminent, or was it postponed?
@odenix commented on GitHub (Oct 15, 2024):
Would you be OK with making this limit configurable in the CLI and Evaluator API?
PS: Is a Pkl release imminent, or was it postponed?
It's imminent! We're targeting an end-of-October release, so, in the next two weeks.
I'd rather not add user-facing knobs here. I think this can be as simple as something like this in GlobResolver:
-private static final int MAX_LIST_ELEMENTS = 16384;
+private static final int MAX_LIST_ELEMENTS = IoUtils.isTestMode() ? 500 : 16384;
@bioball commented on GitHub (Oct 16, 2024):
It's imminent! We're targeting an end-of-October release, so, in the next two weeks.
I'd rather not add user-facing knobs here. I think this can be as simple as something like this in `GlobResolver`:
```diff
-private static final int MAX_LIST_ELEMENTS = 16384;
+private static final int MAX_LIST_ELEMENTS = IoUtils.isTestMode() ? 500 : 16384;
```
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @odenix on GitHub (Oct 15, 2024).
This test takes 15 seconds to run on my machine, hampering developer productivity.
@bioball commented on GitHub (Oct 15, 2024):
Typically, I only include the tests that address the issue I'm working on by adding a filter here: https://github.com/apple/pkl/blob/d00c466843abf1d88abf9d897941fce71334efd4/pkl-core/src/test/kotlin/org/pkl/core/LanguageSnippetTestsEngine.kt#L53
But, if you really want to exclude this test specifically, you can also add it to your excluded tests temporarily:
@odenix commented on GitHub (Oct 15, 2024):
My point is that this test slows down
./gradlew testby 15 seconds, which isn't justified.A common solution for testing the enforcement of a limit is to make the limit configurable and set a lower limit for the test.
@bioball commented on GitHub (Oct 15, 2024):
That sounds like a good solution to this problem
@odenix commented on GitHub (Oct 15, 2024):
Would you be OK with making this limit configurable in the CLI and Evaluator API?
PS: Is a Pkl release imminent, or was it postponed?
@bioball commented on GitHub (Oct 16, 2024):
It's imminent! We're targeting an end-of-October release, so, in the next two weeks.
I'd rather not add user-facing knobs here. I think this can be as simple as something like this in
GlobResolver: