I see that the ET build server is failing for the past two commits. I can only access the commit messages on the build server's web pages, and they point to unrelated Simfactory MDB changes. Is there a way to get a complete diff between the last succeeding and the first failing version?
The error message points to PETSc and how it configures MPI.
-erik
The commit message lists all new commits to ET repositories in each build, so I think those are indeed the only changes to the ET code between revisions. The error is most likely unrelated to the changes in the commits. The last successful build (#322) was done on the CCT build slave, as were all of the previous successful builds I checked. The two most recent builds, however, were done on the Caltech slave (since the CCT machine is temporarily offline) and both of those failed. So I guess there must be some problem with the Caltech build slave.
I have now temporarily disabled the Caltech build slave until someone can fix the problem. Builds will now happen on the Perimeter slave, assuming that is functioning correctly.
On Sun, Nov 9, 2014 at 12:45 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
I see that the ET build server is failing for the past two commits. I can only access the commit messages on the build server's web pages, and they point to unrelated Simfactory MDB changes. Is there a way to get a complete diff between the last succeeding and the first failing version?
The error message points to PETSc and how it configures MPI.
-erik
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/ _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello all,
The commit message lists all new commits to ET repositories in each build, so I think those are indeed the only changes to the ET code between revisions. The error is most likely unrelated to the changes in the commits. The last successful build (#322) was done on the CCT build slave, as were all of the previous successful builds I checked. The two most recent builds, however, were done on the Caltech slave (since the CCT machine is temporarily offline) and both of those failed. So I guess there must be some problem with the Caltech build slave.
The Caltech slave will currently always fail since it was updated to Ubuntu 14.04 but the simfactory option list that the build system uses does not work with this version of Ubuntu (since the mpich include files moved). I can switch back the slave to the "old" Ubuntu version (there's a snapshot of the virtual machine for this reason). I cannot I think update the option list used in simfactory.
I have now temporarily disabled the Caltech build slave until someone can fix the problem. Builds will now happen on the Perimeter slave, assuming that is functioning correctly.
Thank you.
Yours, Roland
On 10 Nov 2014, at 08:26, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello all,
The commit message lists all new commits to ET repositories in each build, so I think those are indeed the only changes to the ET code between revisions. The error is most likely unrelated to the changes in the commits. The last successful build (#322) was done on the CCT build slave, as were all of the previous successful builds I checked. The two most recent builds, however, were done on the Caltech slave (since the CCT machine is temporarily offline) and both of those failed. So I guess there must be some problem with the Caltech build slave.
The Caltech slave will currently always fail since it was updated to Ubuntu 14.04 but the simfactory option list that the build system uses does not work with this version of Ubuntu (since the mpich include files moved). I can switch back the slave to the "old" Ubuntu version (there's a snapshot of the virtual machine for this reason). I cannot I think update the option list used in simfactory.
Hi Roland,
The optionlist used by the build and test system is in https://bitbucket.org/ianhinder/cactusjenkins/src/ (called build.cfg) and you now have commit access.
The change appears to be backward-compatible; please feel free to commit it if this is the case.
I have now temporarily disabled the Caltech build slave until someone can fix the problem. Builds will now happen on the Perimeter slave, assuming that is functioning correctly.
Thank you.
Sorry, I didn't realise that this had happened. The build nodes are all supposed to be identical; if we update one of them for testing, it should be taken out of the pool. Once the testing node is working, we should update the other nodes as well.
On 9 Nov 2014, at 18:45, Erik Schnetter schnetter@cct.lsu.edu wrote:
I see that the ET build server is failing for the past two commits. I can only access the commit messages on the build server's web pages, and they point to unrelated Simfactory MDB changes. Is there a way to get a complete diff between the last succeeding and the first failing version?
Hi Erik,
The build system shows you the commit message recorded in the super-repository for each change, including the commits in the submodules. If everything is working well, this is usually enough to tell what is wrong. If you want to be more certain, and not rely on the commit messages in the super-repo or submodules being accurate, you can check the exact differences as follows.
First check out the git super-repository containing the Einstein Toolkit:
git clone --recursive https://bitbucket.org/einsteintoolkit/einsteintoolkit.git
Next identify the two commits that you want to compare. You can get these from Jenkins by clicking on the build and reading what it says next to "Revision". In this case, the commits are 63280a1829c497e99fc45e6e5e3c929b605a52ca and cf35c92b2c588220e3902817e43a76d33bcd412e.
You can get the changes in the super-repository with
git diff 63280a1829c497e99fc45e6e5e3c929b605a52ca..cf35c92b2c588220e3902817e43a76d33bcd412e
This does not recurse into the submodules and show their diffs, it just reports the change to the version of the submodule. It would be nice if there was a built-in way to do this easily in Git, but there isn't. Instead, you can use this
while read a submodule range; do (echo "Submodule $submodule"; cd $submodule; git diff ${range%*:}); done < <(git diff --submodule 63280a1829c497e99fc45e6e5e3c929b605a52ca..cf35c92b2c588220e3902817e43a76d33bcd412e|grep '^Submodule')
This will give you the complete diffs of all submodule changes between the two super-repository commits.
users@lists.einsteintoolkit.org
-
Barry Wardell -
Erik Schnetter -
Ian Hinder -
Roland Haas