Okay, I've heard enough.
Since Matt is in the process of restarting Hudson, we'll move the
(now local) jobs filesystem back to /shared/jobs.
As John points out, if you're already moved to using http to access
build artifacts or other Hudson info, you have nothing more to do.
If you had manually rigged your script to copy files INTO
/shared/jobs, you'll need to revert your changes. I'll contact
Stephane Bouchet directly to make sure he sees this.
I really apologize for the problems this has caused; I didn't think
so many people were reading files directly in /shared/jobs.
Denis
On 12/14/2011 01:42 PM, John Arthorne wrote:
Denis Roy wrote on 12/14/2011
01:29:09 PM:
> In the immediate term, can I safely assume that reverting
/shared/
> jobs to the way it was will FIX many problems?
It sounds like it would be helpful to people in
the
short term to do this. I would suggest for those people who
have already
adapted their build to avoid reaching into the hudson
workspace from outside,
that they keep it that way. I know in my Hudson build,
although the timing
could have been better, I am now in better shape using
official Hudson
HTTP API to interact with my job rather than reaching into the
file system.
It would be good to know from others with more Hudson
experience whether
this is a generally accepted good practice. Remotely accessing
the file
system of a build that may be currently running just feels
error prone
to me. I can imagine easily breaking a build by locking a file
the build
is attempting to delete, etc. But, if this is the right answer
I'm all
for staging that change more carefully so people can hit their
build schedules...
John
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Denis Roy
|
