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.
