Build / Test Issues

[HyperplaneOrg]

While attempting to build Ziggy in an Amazon Linux 2 container, I encountered a few issues with the build and testing phases.

1. If one downloads the release package and attempts to build the System, it fails due to the way versioning is done in ZiggyVersionGenerator.java. The version generator requires that the source tree reside in a git repository, but when one downloads the release package, it is not in a git repository, so the build fails. Note if one clones the source, e.g., git clone https://github.com/nasa/ziggy.git && cd ziggy, and then attempts to build the System this failure does not occur.

2. Several tests fail, e.g., gov.nasa.ziggy.module.remote.nas.NasQueueTimeMetricsTest > testSmdMetrics FAILED
   java.lang.NullPointerException
   at java.base/java.io.File.(File.java:318)
   at gov.nasa.ziggy.module.remote.nas.NasQueueTimeMetrics.fullDestination(NasQueueTimeMetrics.java:96)
   at gov.nasa.ziggy.module.remote.nas.NasQueueTimeMetrics.populate(NasQueueTimeMetrics.java:92)
   at gov.nasa.ziggy.module.remote.nas.NasQueueTimeMetrics.queueDepth(NasQueueTimeMetrics.java:198)
   at gov.nasa.ziggy.module.remote.nas.NasQueueTimeMetricsTest.testValues(NasQueueTimeMetricsTest.java:98)
   at gov.nasa.ziggy.module.remote.nas.NasQueueTimeMetricsTest.testSmdMetrics(NasQueueTimeMetricsTest.java:76)

which is because the environmental variable "USER" may not be available, and gov/nasa/ziggy/module/remote/nas/NasQueueTimeMetrics.java (line 96) requires System.getenv("USER") to succeed, but in some environments it will not, hence the failure of these specific tests in certain environments. As an aside, some considered this approach of creating temp directories, or files, as bad practice; it can be regarded as potentially unsafe/insecure. Have you considered using something like Files.createTempDirectory?

[wohler]

Thanks, Andy!

1. Hopefully, GitHub provides a means to generate a properties file from a Gradle task for inclusion in their tarball. I'll resolve this in any case. (ZIGGY-253)
2. On your system, is there an equivalent of USER environment variable? We do use the current user in our properties file, but we can make a note in the manual about this. In code, we can use the java user.name system property, which should be available even on your system. Does java -XshowSettings:properties -version 2>&1 | grep user.name give you something reasonable? (ZIGGY-254)
3. Agreed, to some extent. Consider /run/user that contains directories for each user on the system, which contains more sensitive data. As long as the permissions are closed to others, there shouldn't be much of a problem. That said, we'll investigate the files created in /tmp. (ZIGGY-255)

[HyperplaneOrg]

The java -XshowSettings:properties -version 2>&1 | grep user.name gives a result, but given the directory(ies) are created based on getenv("USER"), which returns null, the post-build tests fail. The system we are running on does not have the USER environment variable set at runtime, but we will make sure to explicitly set it before any build/tests going forward. If you make a note of this potential issue it might be helpful for others, as it took me sometime to understand why some of the post-build tests were failing.

[wohler]

Thanks for confirming that the user.name property exists and is reasonable. I'll update the code to use the user.name property rather than the USER environment variable, so you won't have to use that workaround forever.