Show
added a comment - I've tested producing the docs with both datarel and lsst_apps as makeDocs targets. The results are identical except for eups +versions and timestamps.
LSST_COMPILER=devtoolset- 6 LSST_PYTHON_VERSION= 3 PRODUCT=lsst_apps BRANCH=w. 2017.49 WORKSPACE=$PWD SKIP_DEMO= true ./ci-scripts/jenkins_wrapper.sh
LSST_COMPILER=devtoolset- 6 LSST_PYTHON_VERSION= 3 PRODUCT=datarel BRANCH=w. 2017.49 WORKSPACE=$PWD SKIP_DEMO= true ./ci-scripts/jenkins_wrapper.sh
The former had all of the references to the datarel package in ci-scripts/create_xlinkdocs.sh replaced with lsst_apps .
# diff -u index.html-lsst_apps index.html-datarel
--- index.html-lsst_apps 2017 - 12 - 19 23 : 45 : 24.930072951 + 0000
+++ index.html-datarel 2017 - 12 - 19 23 : 49 : 11.890783323 + 0000
@@ - 28 , 7 + 28 , 7 @@
<tr style= "height: 56px;" >
<td id= "projectalign" style= "padding-left: 0.5em;" >
<div id= "projectname" >LSSTApplications
- &# 160 ;<span id= "projectnumber" > 11.0 - 22 -g33de520, 14.0 + 19 , 14.0 + 28 , 14.0 + 4 , 14.0 - 1 -g013352c+ 11 , 14.0 - 1 -g13ef843+ 8 , 14.0 - 1 -g2fa83af+ 26 , 14.0 - 1 -g3019bb2+ 13 , 14.0 - 1 -g4b114ac+ 9 , 14.0 - 1 -g7257b6a+ 8 , 14.0 - 1 -g8b7e855+ 27 , 14.0 - 1 -ge6e5c2d+ 17 , 14.0 - 1 -ge993229+ 26 , 14.0 - 10 -ga7aaa25+ 4 , 14.0 - 12 -g233aa8e+ 9 , 14.0 - 14 -g87d16e8+ 5 , 14.0 - 18 -g0eec5f5+ 10 , 14.0 - 2 -g0af5a6c+ 27 , 14.0 - 2 -g319577b+ 6 , 14.0 - 2 -g8373656+ 6 , 14.0 - 2 -ga5af9b6+ 6 , 14.0 - 25 -g0e8fc950e+ 7 , 14.0 - 28 -gf7234cf5+ 2 , 14.0 - 4 -g4cc409d+ 17 , 14.0 - 4 -ge2d7f21+ 6 , 14.0 - 5 -g86eb1bd+ 7 , 14.0 - 6 -g4f52afe+ 5 , 14.0 - 6 -ge2c9487+ 18 , 14.0 - 6 -gf4bc96c+ 27 , 14.0 - 8 -g7f6dd6b+ 5 , 14.0 - 8 -gf6dacf9e+ 5 </span>
+ &# 160 ;<span id= "projectnumber" > 11.0 - 22 -g33de520, 14.0 + 28 , 14.0 + 31 , 14.0 + 4 , 14.0 - 1 -g013352c+ 11 , 14.0 - 1 -g13ef843+ 8 , 14.0 - 1 -g4b114ac+ 9 , 14.0 - 1 -g7257b6a+ 8 , 14.0 - 1 -g8b7e855+ 27 , 14.0 - 10 -ga7aaa25+ 4 , 14.0 - 12 -g233aa8e+ 9 , 14.0 - 14 -g87d16e8+ 5 , 14.0 - 18 -g0eec5f5+ 10 , 14.0 - 2 -g0af5a6c+ 27 , 14.0 - 2 -g319577b+ 6 , 14.0 - 2 -g8373656+ 6 , 14.0 - 2 -ga5af9b6+ 6 , 14.0 - 25 -g0e8fc950e+ 7 , 14.0 - 28 -gf7234cf5+ 2 , 14.0 - 4 -g4cc409d+ 17 , 14.0 - 4 -ge2d7f21+ 6 , 14.0 - 5 -g86eb1bd+ 7 , 14.0 - 6 -g4f52afe+ 5 , 14.0 - 6 -ge2c9487+ 18 , 14.0 - 6 -gf4bc96c+ 27 , 14.0 - 8 -g7f6dd6b+ 5 , 14.0 - 8 -gf6dacf9e+ 5 </span>
</div>
<div id= "projectbrief" >LSSTDataManagementBasePackage</div>
</td>
@@ - 214 , 7 + 214 , 7 @@
</div></div><!-- contents -->
<!-- start footer part -->
<hr class = "footer" /><address class = "footer" ><small>
-Generated on Tue Dec 19 2017 23 : 03 : 34 for LSSTApplications by &# 160 ;<a href= "http://www.doxygen.org/index.html" >
+Generated on Tue Dec 19 2017 23 : 48 : 15 for LSSTApplications by &# 160 ;<a href= "http://www.doxygen.org/index.html" >
<img class = "footer" src= "doxygen.png" alt= "doxygen" />
</a> 1.8 . 13
</small></address>
lsst/lsstsw has not changed
lsst-sqre/ci-scripts/create_xlinkdocs.sh has not changed
lsst/doxygen has not changed
lsst/lsstDoxygen has not changed
lsst/base has not changed
lsst/sconsUtils has recent changes but are too recent to have affected Dec. 1st.
The only changed I can think of that was around that time was the switch to running inside of a container: https://github.com/lsst-sqre/jenkins-dm-jobs/pull/284 I suppose that could have slightly changed the version of something doxygen is linking against or perhaps some env vars. The migration to devtoolset-6 came a few days later: https://github.com/lsst-sqre/jenkins-dm-jobs/pull/301 I also can't rule out that a change in some other random product has caused doxygen to change behavior – I need to test with @timj's eups patch to rule that out.
ldd doxygen
linux-vdso.so. 1 => ( 0x00007ffdbf1fd000 )
libpthread.so. 0 => /lib64/libpthread.so. 0 ( 0x00007f1e2d836000 )
libstdc++.so. 6 => /lib64/libstdc++.so. 6 ( 0x00007f1e2d52d000 )
libm.so. 6 => /lib64/libm.so. 6 ( 0x00007f1e2d22b000 )
libgcc_s.so. 1 => /lib64/libgcc_s.so. 1 ( 0x00007f1e2d015000 )
libc.so. 6 => /lib64/libc.so. 6 ( 0x00007f1e2cc51000 )
/lib64/ld-linux-x86- 64 .so. 2 ( 0x0000555f40fbb000 )
Choices are the linux kernel, glibc, or the gcc 4.8.5 shared libs. (also note that, oddly, doxygen linking against the system gcc libs instead of /opt/rh/devtoolset-6/root/usr/lib/gcc/x86_64-redhat-linux/6.3.1/32/libgcc_s.so ).
The kernel changed from 3.10.0-693.5.2 -> 3.10.0-693.5.2 on Nov 28th but I would be shocked if the kernel stub functions would cause this kind of breakage.
The jenkins VM versions:
$ rpm -q glibc gcc
glibc- 2.17 - 106 .el7_2. 1 .x86_64
gcc- 4.8 . 5 - 4 .el7.x86_64
Versions in docker.io/lsstsqre/centos:7-stackbase (Switched to shortly before devtoolset-6 was implemented):
# rpm -q glibc gcc
glibc- 2.17 - 196 .el7.x86_64
gcc- 4.8 . 5 - 16 .el7.x86_64
Versions in docker.io/lsstsqre/centos:7-stackbase-devtoolset-6 :
# rpm -q glibc gcc
glibc- 2.17 - 196 .el7.x86_64
gcc- 4.8 . 5 - 16 .el7.x86_64
I will repeat the same test directly on a jenkins build VM image to check for glibc/gcc changes as a cause.
Kian-Tat Lim Could you provide instructions to reproduce the original doxygen structure on centos-7, preferably in the docker.io/lsstsqre/centos:7-stackbase-devtoolset-6 docker image? I am not very familiar with the doxygen build and I'm at a bit of a loss.
I would be quiet surprised if pipe_base.html was being accidentally renamed to index.html and the console output does show index.html being pushed to s3 last night:
https://ci.lsst.codes/blue/rest/organizations/jenkins/pipelines/release/pipelines/run-rebuild/runs/506/nodes/261/steps/274/log/?start=0
I'm wonder if there is some sort of environmental sensitivity...