You are viewing a plain text version of this content. The canonical link for it is here.
Posted to builds@apache.org by Andrew Bayer <an...@gmail.com> on 2014/05/15 22:55:21 UTC
Heads up - Planning to disable anonymous workspace read access on builds.a.o
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.
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by Hervé BOUTEMY <he...@free.fr>.
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.
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by Hervé BOUTEMY <he...@free.fr>.
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.
Re: Heads up - Planning to disable anonymous workspace read access
on builds.a.o
Posted by Martin Desruisseaux <de...@apache.org>.
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.
>
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by Hervé BOUTEMY <he...@free.fr>.
since every committer can have an authenticated access to Jenkins, this seems
reasonable to me
notice I don't really get what is "the archive artifacts functionality": any
pointer appreciated, and I'll try to add explanations to our Jenkins best
practices [1]
> am going to contact the Maven team
> regarding what looks to be build usage of bits from some of their jobs'
> workspaces
are you talking about the dist-tool report [2], or something else?
Is a generated site like workspace or like archive?
Thank you for the hard work done.
Regards,
Hervé
[1]
http://wiki.apache.org/general/Jenkins#Are_there_recommended_or_mandatory_Jenkins_settings_for_ASF_projects.3F
[2] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
Le jeudi 15 mai 2014 13:55:21 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.
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by Andrew Bayer <an...@gmail.com>.
As an experiment, I'm now disabling *all* workspace read access to see if
that helps with hanging problems. FYI.
A.
On Wed, May 21, 2014 at 10:34 AM, Andrew Bayer <an...@gmail.com>wrote:
> I've now removed anonymous read access to workspaces - let me know if
> there are any issues.
>
> A.
>
>
> On Wed, May 21, 2014 at 1:33 PM, Andrew Bayer <an...@gmail.com>wrote:
>
>> That's fine usage, at least so long as there isn't another option out
>> there.
>>
>> A.
>>
>>
>> On Tue, May 20, 2014 at 9:02 PM, Roman Shaposhnik <rv...@apache.org> wrote:
>>
>>> On Tue, May 20, 2014 at 4:23 PM, Andrew Bayer <an...@gmail.com>
>>> wrote:
>>> > Frankly, I'm fine with using jenkins archived artifacts for that -
>>> that's
>>> > not heavy load in my experience, though I'll watch out for any
>>> problems. The
>>> > issue has been serving files out of the slave workspace.
>>>
>>> I guess I wasn't explaining it well. Here's what I'm currently abusing
>>> Jenkins for:
>>>
>>> https://builds.apache.org/view/E-G/view/Giraph/job/Giraph-trunk-site/lastSuccessfulBuild/artifact/target/staging/
>>>
>>> This is a build of Giraph website that I would like to "publish" as
>>> part of our continuous integration efforts. Currently that
>>> publishing mechanism is to use URLs coming out of Jenkins. E.g.:
>>>
>>> https://builds.apache.org/view/E-G/view/Giraph/job/Giraph-trunk-site/lastSuccessfulBuild/artifact/target/staging/index.html
>>>
>>> I'd love to stop doing this, but I'm honestly not sure what
>>> else I can use.
>>>
>>> Thanks,
>>> Roman.
>>>
>>
>>
>
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by Andrew Bayer <an...@gmail.com>.
I've now removed anonymous read access to workspaces - let me know if there
are any issues.
A.
On Wed, May 21, 2014 at 1:33 PM, Andrew Bayer <an...@gmail.com>wrote:
> That's fine usage, at least so long as there isn't another option out
> there.
>
> A.
>
>
> On Tue, May 20, 2014 at 9:02 PM, Roman Shaposhnik <rv...@apache.org> wrote:
>
>> On Tue, May 20, 2014 at 4:23 PM, Andrew Bayer <an...@gmail.com>
>> wrote:
>> > Frankly, I'm fine with using jenkins archived artifacts for that -
>> that's
>> > not heavy load in my experience, though I'll watch out for any
>> problems. The
>> > issue has been serving files out of the slave workspace.
>>
>> I guess I wasn't explaining it well. Here's what I'm currently abusing
>> Jenkins for:
>>
>> https://builds.apache.org/view/E-G/view/Giraph/job/Giraph-trunk-site/lastSuccessfulBuild/artifact/target/staging/
>>
>> This is a build of Giraph website that I would like to "publish" as
>> part of our continuous integration efforts. Currently that
>> publishing mechanism is to use URLs coming out of Jenkins. E.g.:
>>
>> https://builds.apache.org/view/E-G/view/Giraph/job/Giraph-trunk-site/lastSuccessfulBuild/artifact/target/staging/index.html
>>
>> I'd love to stop doing this, but I'm honestly not sure what
>> else I can use.
>>
>> Thanks,
>> Roman.
>>
>
>
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by Andrew Bayer <an...@gmail.com>.
That's fine usage, at least so long as there isn't another option out there.
A.
On Tue, May 20, 2014 at 9:02 PM, Roman Shaposhnik <rv...@apache.org> wrote:
> On Tue, May 20, 2014 at 4:23 PM, Andrew Bayer <an...@gmail.com>
> wrote:
> > Frankly, I'm fine with using jenkins archived artifacts for that - that's
> > not heavy load in my experience, though I'll watch out for any problems.
> The
> > issue has been serving files out of the slave workspace.
>
> I guess I wasn't explaining it well. Here's what I'm currently abusing
> Jenkins for:
>
> https://builds.apache.org/view/E-G/view/Giraph/job/Giraph-trunk-site/lastSuccessfulBuild/artifact/target/staging/
>
> This is a build of Giraph website that I would like to "publish" as
> part of our continuous integration efforts. Currently that
> publishing mechanism is to use URLs coming out of Jenkins. E.g.:
>
> https://builds.apache.org/view/E-G/view/Giraph/job/Giraph-trunk-site/lastSuccessfulBuild/artifact/target/staging/index.html
>
> I'd love to stop doing this, but I'm honestly not sure what
> else I can use.
>
> Thanks,
> Roman.
>
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by Roman Shaposhnik <rv...@apache.org>.
On Tue, May 20, 2014 at 4:23 PM, Andrew Bayer <an...@gmail.com> wrote:
> Frankly, I'm fine with using jenkins archived artifacts for that - that's
> not heavy load in my experience, though I'll watch out for any problems. The
> issue has been serving files out of the slave workspace.
I guess I wasn't explaining it well. Here's what I'm currently abusing
Jenkins for:
https://builds.apache.org/view/E-G/view/Giraph/job/Giraph-trunk-site/lastSuccessfulBuild/artifact/target/staging/
This is a build of Giraph website that I would like to "publish" as
part of our continuous integration efforts. Currently that
publishing mechanism is to use URLs coming out of Jenkins. E.g.:
https://builds.apache.org/view/E-G/view/Giraph/job/Giraph-trunk-site/lastSuccessfulBuild/artifact/target/staging/index.html
I'd love to stop doing this, but I'm honestly not sure what
else I can use.
Thanks,
Roman.
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by Andrew Bayer <an...@gmail.com>.
Frankly, I'm fine with using jenkins archived artifacts for that - that's
not heavy load in my experience, though I'll watch out for any problems.
The issue has been serving files out of the slave workspace.
A.
On Sunday, May 18, 2014, Roman Shaposhnik <rv...@apache.org> wrote:
> On Fri, May 16, 2014 at 8:48 PM, David Nalley <david@gnsa.us<javascript:;>>
> wrote:
> > On Thu, May 15, 2014 at 4:55 PM, Andrew Bayer <andrew.bayer@gmail.com<javascript:;>>
> wrote:
> >> 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?
> >>
> >
> > Makes sense to me.
> > Jenkins is not a web server; and projects shouldn't be using it as such.
>
> Agreed 100%, but... ;-)
>
> ...what would be a recommend way to publish file trees for
> the purposes of lets say contibnuos integration of things
> like project websites and javadocs? IOW, which real webserver
> on the ASF infra can serve that purpose?
>
> Thanks,
> Roman.
>
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by Roman Shaposhnik <rv...@apache.org>.
On Fri, May 16, 2014 at 8:48 PM, David Nalley <da...@gnsa.us> wrote:
> On Thu, May 15, 2014 at 4:55 PM, Andrew Bayer <an...@gmail.com> wrote:
>> 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?
>>
>
> Makes sense to me.
> Jenkins is not a web server; and projects shouldn't be using it as such.
Agreed 100%, but... ;-)
...what would be a recommend way to publish file trees for
the purposes of lets say contibnuos integration of things
like project websites and javadocs? IOW, which real webserver
on the ASF infra can serve that purpose?
Thanks,
Roman.
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by Gavin McDonald <ga...@16degrees.com.au>.
Thanks Andrew for looking into this.
Please go ahead and make the necessary changes once you are ready.
Gav…
On 17/05/2014, at 4:48 AM, David Nalley <da...@gnsa.us> wrote:
> On Thu, May 15, 2014 at 4:55 PM, Andrew Bayer <an...@gmail.com> wrote:
>> 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?
>>
>
> Makes sense to me.
> Jenkins is not a web server; and projects shouldn't be using it as such.
>
> --David
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by David Nalley <da...@gnsa.us>.
On Thu, May 15, 2014 at 4:55 PM, Andrew Bayer <an...@gmail.com> wrote:
> 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?
>
Makes sense to me.
Jenkins is not a web server; and projects shouldn't be using it as such.
--David
Re: Heads up - Planning to disable anonymous workspace read access on builds.a.o
Posted by Olivier Lamy <ol...@apache.org>.
+1
--
Olivier
On May 17, 2014 5:00 AM, "Andrew Bayer" <an...@gmail.com> wrote:
> 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.
>