-
Notifications
You must be signed in to change notification settings - Fork 242
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 the mismatching default configs in integration tests #11283
Fix the mismatching default configs in integration tests #11283
Conversation
integration_tests/src/main/scala/com/nvidia/spark/rapids/tests/DumpDefaultConfigs.scala
Outdated
Show resolved
Hide resolved
integration_tests/src/main/scala/com/nvidia/spark/rapids/tests/DumpDefaultConfigs.scala
Outdated
Show resolved
Hide resolved
integration_tests/src/main/scala/com/nvidia/spark/rapids/tests/DumpDefaultConfigs.scala
Outdated
Show resolved
Hide resolved
integration_tests/src/main/scala/com/nvidia/spark/rapids/tests/DumpDefaultConfigs.scala
Outdated
Show resolved
Hide resolved
@@ -124,6 +124,7 @@ abstract class ConfEntry[T](val key: String, val converter: String => T, val doc | |||
|
|||
def get(conf: Map[String, String]): T | |||
def get(conf: SQLConf): T | |||
def getDefault(): T |
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.
It would rather make sense to omit the conf withtout defaults in the dump IMO
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.
So, I think this API should just return whatever the default is. Any business logic should not be involved at this level.
As for DumpDefaultConfigs
, it dumps even those configs without defaults because we would want to unset them for the integration test if they were set somehow.
…a new stage for integration test to populate default configs Signed-off-by: Jihoon Son <[email protected]>
8460739
to
e7f1ec5
Compare
Uh, the CI fails with this error. What should I do about it? I bumped up this dependency version because the |
The CI error seems because of the missing version update in the 2.13 pom file for the corresponding dependency. I will fix it soon. |
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.
Since this is adding a new dependency to the integration tests, it needs to update integration_tests/src/assembly/bin.xml to add the file to the integration tests tarball so CI test pipelines that do not build from source can run the integration tests properly.
@jlowe thanks for catching it. I added the new file in 8dbd354, but I'm not sure if I did it right. I opened up the |
Hmm so the CI is now failing with the error above. I think it's because of some missing JVM options, such as |
As for the CI failure with java 17, to allow access to protected methods via reflection, I have two ideas:
I'm leaning towards to the option 1 only because it is easier. But the option 2 doesn't seem that hard either. Any opinions here? |
We already have an example of running a class as a program with all of its dependencies to generate files during the build which isn't doing any reflection shenanigans and IIUC is working with the JDK17 build. See the update_config_docs rule in dist/pom.xml. Any reason we can't do the same here? |
+1 for following the pattern from update_config_docs. exec plugin executions are run in the Maven JVM, and requiring particular MAVEN_OPTS is unnecessarily user-unfriendly. In Ant java task https://ant.apache.org/manual/Tasks/java.html we can set fork=true and pass the same args we already use for unit tests ${extraJavaTestArgs} as |
Build |
Can someone help to run the CI? I don't seem to have enough power for that. |
Create a PR to add your GH user here
|
build |
The CI is failing because some tests in |
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.
LGTM with one caveat:
Just double-checking:
beyond propagating the classpath, part of the reason why we looked into forking out a JVM for config dump execution is to propagate extra options for JDK17. #11283 (comment)
<target> | ||
<taskdef resource="net/sf/antcontrib/antcontrib.properties"/> | ||
<java classname="com.nvidia.spark.rapids.tests.DumpDefaultConfigs" | ||
failonerror="true" | ||
classpathref="maven.compile.classpath" | ||
fork="true"> | ||
<arg value="json"/> | ||
<arg value="${project.build.directory}/spark-rapids-default-configs.json"/> | ||
</java> | ||
</target> |
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.
Curious why we end up not needing this #11283 (comment)
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.
Good question. I'm not quite sure why it works. I can add those java options here just in case..
I have noticed that the |
NVM. Java 8 seems to fail to have some classpath issue with this change. It could be nice to fix, but I don't think the change that adds |
build |
build |
Hi @jlowe, I have fixed all tests and the CI is green now. Could you have another look? |
sql-plugin/src/main/scala/com/nvidia/spark/rapids/RapidsConf.scala
Outdated
Show resolved
Hide resolved
build |
…DIA#11283)" This reverts commit bc8c577. Signed-off-by: Jihoon Son <[email protected]>
)" (#11347) This reverts commit bc8c577. Signed-off-by: Jihoon Son <[email protected]>
Fixes #11134.
Default values of some configs used in the integration test by default has gone stale as they haven't updated when their defaults changed. This is because we have a separated list of default configs used by the integration test, which should be manually updated along with code change. This PR fixes this problem by dumping all default configs in a file and letting the integration test use it. A new interface,
getDefault
, has been added inConfEntry
. A newDumpDefaultConfigs
class uses this API to dump all default configs in a file. In the integration test, those default configs are loaded when the spark session is initialized.