perhaps I read it too fast: IIUC, that can be like Maven's dist-tool report, ie a "Maven-generate site", as /site/ url, and not the /ws/target/site/ url which is the content from workspace
If I read dist-tool output correctly [1] [JENKINS] Archiving site from /home/jenkins/jenkins-slave/workspace/dist-tool- plugin/target/site to /x1/jenkins/jenkins-home/jobs/dist-tool-plugin/site means that /site/ is an archived version of the workspace content, so don't suffer from JENKINS-23056 that's it? Regards, Hervé [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/470/console Le samedi 17 mai 2014 08:38:58 Hervé BOUTEMY a écrit : > no, the workflow wouldn't be applicable with Jenkins: IMHO, such workflow > should be published on Mahout website, with svnpubsub and extpaths.txt to > avoid javadoc disappearing on each CMS change > > Regards, > > Hervé > > Le vendredi 16 mai 2014 23:28:59 Martin Desruisseaux a écrit : > > Hello Andrew > > > > Thanks for looking at this issue. On my side, I use the javadoc > > generated by Jenkins build every days. I often fix formatting issues and > > wait for the next Jenkins build for seeing if the fix worked. This is > > especially useful in class javadoc having tables, matrices or > > mathematical formulas. > > > > I also use Javadoc for getting API feedback from the community: I > > provide some skeleton classes with lot of Javadoc, send the link to the > > developer mailing list for comments, modify the API according feedback, > > wait for Jenkins to update the javadoc, etc. in an iterative process. > > > > Would such workflow still be applicable? > > > > Martin > > > > Le 15/05/14 22:55, Andrew Bayer a écrit : > > > So from https://issues.jenkins-ci.org/browse/JENKINS-23056 it sounds > > > like > > > at least one of the problems we're having with Jenkins hanging is > > > because > > > of attempts to access the workspace of jobs through the UI - when a > > > slave > > > is slow or hanging and that kind of request is made, it can lock up the > > > whole UI. I've contacted the Mahout team regarding their linking to > > > javadocs in job workspaces, and am going to contact the Maven team > > > regarding what looks to be build usage of bits from some of their jobs' > > > workspaces, but I'd also like to nip this in the bud permanently by > > > requiring authentication for access to job workspaces. > > > > > > My thinking is that the only legitimate reason to be accessing the > > > workspace is if you need to in order to debug a failed build - > > > otherwise, > > > if there's something that you want to be publishing from your build, you > > > can use the archive artifacts functionality. Does this sound reasonable > > > to > > > everyone? > > > > > > A.
