search

geodynamics / vq

Virtual Quake is a boundary element code designed to investigate long term fault system behavior and interactions between faults through stress transfer.
Other
12 stars 24 forks source link

Create Jenkinsfile for new Jenkins build system #196

Closed tjesser-ucdavis-edu closed 6 years ago

tjesser-ucdavis-edu commented 6 years ago

The only tests that are failing are the mpi ones that complain about being root. I think the ASPECT devs dealt with the problem by using the mpirun flag --allow-run-as-root, but I couldn't find a place to put it in vq.

I'd eventually like to figure out some way to switch from downloading all the Ubuntu packages every build, but the package list being in the Jenkinsfile is really helpful documentation. I'm not sure how visible it would be if we used a prepared container.

Also, would it be better to test on 18.04 instead of 16.04?

Virtual Quake devs, please let me know if you have any feedback on the new Jenkins/Github integration. I'm not sure if you would prefer here or the mailing list.

johnmaxwilson commented 6 years ago

This thread is preferred to the mailing list for communication, I think. We're still running VQ primarily on machines running Mint 18, which is based on Ubuntu 16, so I'm fine with 16.04 for now. As to the mpirun flag, the place to stick that would be in examples/CMakeLists.txt, line 79, where the mpiexec tests are put together. See if that solves the fails and then we can merge this in.

tjesser-ucdavis-edu commented 6 years ago

Looks like we need to add the flag to more lines. We did go from 33 tests complaining to just 9.

johnmaxwilson commented 6 years ago

Whoops, missed a couple. Also in lines 227 and 239.

tjesser-ucdavis-edu commented 6 years ago

Hurray, all tests passing! You might want to squash-merge this. I don't see the need to keep all the individual commits.

Do you have any suggestions about making the package list easily accessible if we move to a container with packages preinstalled?

johnmaxwilson commented 6 years ago

Our README/INSTALL files could use an update with full package list, would that satisfy what you had in mind?

tjesser-ucdavis-edu commented 6 years ago

Hmm, I guess I'm worried that we'll have the list of packages in the Readme, but it won't be easy to make sure that list matches what is actually in the prebuilt container.

Although, now that I think about it, this repo already has a Dockerfile in it that is being used to create a container. Storing the Dockerfile for the test container here would solve the problem, I think, and it would be easy to see that it matches what's in the Readme.

I should read up on how Dockerhub autobuilds containers. Is that what we are doing for the user container?

johnmaxwilson commented 6 years ago

Currently we've been building it by hand each release, but automating the process would be great. I'll look into that as well.