Open lesserwhirls opened 7 years ago
This test is also failing in the same way on Jenkins. It works on my machine under intellij, so my speculation is that we need to upgrade the netcdf-c jna installation on travis and jenkins. We probably need to enable logging support for netcdf-4 when it is installed.
We are using 4.1.1
, but could probably bump to 4.1.1.1
. Or, should we wait until the next release of netCDF-C?
...my PR just passed on travis without issue...
https://travis-ci.org/lesserwhirls/thredds/builds/255838524?utm_source=email&utm_medium=notification
wait...it failed on the Unidata travis run
Ok, one ran on Ubuntu precise (Passed), the other ran on Trusty (failed). See Unidata/thredds#898. I just made a PR to pin our travis version to precise to keep thing going for now.
This is not good when the underlying OS [version] is involved in the failure.
I think it's because some of the os libraries that netCDF-C is linked against changed with the OS bump.
I can spin up a Vagrant box and quickly generate the new binaries. But weren't we waiting on a new version of netcdf-c? And didn't we want to build with certain flags enabled? Can I get a summary of all that?
Yeah, I thought we were waiting for the next release, so let's hold off until that happens. Travis is working again now that the version of Ubuntu is pinned. @DennisHeimbigner mentioned building with logging enabled, which would be the --enable-logging
flag. Except for the CPPFLAGS
and LDFLAGS
in-line env variables, I don't think we need to use any other special flags on our test machines (no more --enable-threadsafe
on the HDF build). Although, on our production machines, I turn off dap simply because it's not needed, so that one would be --disable-dap
.
So, I would say, for netCDF-C specifically:
CPPFLAGS=<path to /include dir with HDF headers>
LDFLAGS=<path to /lib dir with HDF libs>
--disable-dap
--enable-logging
Everything else should be ok with vanilla or whatever the OS provides.
@DennisHeimbigner - where do the netCDF-C generated logs get dumped? It would be good to include those in the S3 Store (with a link in the testing output) so we can examine them after the tests run, much like we do on travis currently for output from our test suite.
That set of flags looks good. By default, the log output gets sent to stdout (or maybe stderr). However nothing is generated unless logging is turned on. The reason I would like it enabled is so we can turn it on as needed to help debug problems like the one in this issue. If it turns out that, for some reason, that log output is causing problems, then we can disable it again.
See http://unidata-tds.s3.amazonaws.com/Travis/5.0.0-4483/4483.1/classes/dap4.test.TestServlet.html