Am 07.12.11 17:07, schrieb Denis Roy:
> Although we don't encourage projects to allow Hudson writing to their
> downloads area, we don't prohibit it since we understand the convenience
> this practice offers. If you feel this is the right solution for your
> project, then by all means, go for it.
On 12/07/2011 10:23 AM, Dennis Hübner wrote:
> Sounds like a solution that will work...
> Till someone says we have not enough hard drive space and need new
> storage devices,
> or mirror server can't mirror download.eclipse.org because it's to huge.
Dennis,
I certainly understand your frustration
As a middle ground, you can grant Hudson write access to a staging location
and then promote artifacts from there to your actual download location with
more restrictive permissions (manually or using a cron on build.eclipse.org
).
In the end we all need to trust Hudson anyways to the extend that t
Am 07.12.11 16:13, schrieb Steffen Pingel:
> We had similar problems when downloading artifacts from Hudson. Often
> downloads would time out or get corrupted during the download.
>
> We resolved it by copying the artifacts to a different location as the last
> step in the build, e.g. to a director
On Wed, Dec 7, 2011 at 2:17 PM, Dennis Hübner wrote:
> Am 07.12.11 14:09, schrieb Denis Roy:
>
> Well, then we have a problem.
>
> /shared is a NFS-mounted filesystem which is shared amongst all the
> build/hudson servers. The NFS mount is problematic since you can't
> clean your workspace.
>
>
Am 07.12.11 15:44, schrieb Webmaster(Matt Ward):
> 3) You can use the http/s links to get the files and put them where
> your releng scripts expect, then run your release tools. After that
> you can work on updating your tools.
... and then? Wait for the next "potential fix"?
Now I understand rel
I think there are any other options, we need a read only file system
access on build.eclipse.org that points to Hudson's jobs/ folder.
I'm unable to find a way to do this. Basically we'd need it to be rw in
both locations and that is a recipe for trouble(just a different kind
than before).
On Dec 7, 2011, at 2:53 PM, Denis Roy wrote:
>
> On 12/07/2011 08:43 AM, Sven Efftinge wrote:
>>
>>
>> On Dec 7, 2011, at 2:09 PM, Denis Roy wrote:
>>> So we moved /shared/jobs to a locally-mounted filesystem, which is not
>>> shared.
>>
>> So if this is the problem. Why can't you make it
Am 07.12.11 14:32, schrieb Denis Roy:
> I guess that's worse than Hudson over NFS, which is fragile but fast? :-)
It's pretty stable in getting artifacts without Bad Gateway 503 errors
(or sometimes just 0byte jars ^^, bad checksums etc.)
> I understand... But what are the options? A shared filesys
On 12/07/2011 08:43 AM, Sven Efftinge wrote:
>
> On Dec 7, 2011, at 2:09 PM, Denis Roy wrote:
>> So we *moved /shared/jobs* to a locally-mounted filesystem, which is
>> *not shared*.
>
> So if this is the problem. Why can't you make it shared again?
>
I don't understand. Is that a trick questio
On Dec 7, 2011, at 2:09 PM, Denis Roy wrote:
> So we moved /shared/jobs to a locally-mounted filesystem, which is not
> shared.
So if this is the problem. Why can't you make it shared again?
Sven
___
cross-project-issues-dev mailing list
cross-pro
On 12/07/2011 08:17 AM, Dennis Hübner wrote:
Am 07.12.11 14:09, schrieb Denis Roy:
Well, then we have a problem.
/shared is a NFS-mounted filesystem which is shared amongst all the
build/hudson servers. The NFS mount is problematic since you can't
clean
We had this problem a while ago but more with target platforms, where p2 would
pull in the optional dependencies never the less they were optional. What we
did is added a p2.inf file to the META-INF directory of each bundle with RAP
dependencies with this content:
---
requires.0.nam
Am 07.12.11 14:09, schrieb Denis Roy:
> Well, then we have a problem.
>
> /shared is a NFS-mounted filesystem which is shared amongst all the
> build/hudson servers. The NFS mount is problematic since you can't
> clean your workspace.
>
> So we *moved /shared/jobs* to a locally-mounted filesystem,
Well, then we have a problem.
/shared is a NFS-mounted filesystem which is shared amongst all the
build/hudson servers. The NFS mount is problematic since you can't
clean your workspace.
So we *moved /shared/jobs* to a locally-mounted filesystem, which is
*not shared*. As far as I understand it
Hello Folks,
we, the Jubula team, are currently experiencing problems with the
inclusion of optional bundles (RAP) dependencies when installing our
feature into the IDE and / or packaging our feature for Juno "Eclipse
for testers" (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=365865).
I
Xtext and MWE are going to have a release today.
But the problems Dennis mentioned are holding us back.
Sven
On Dec 7, 2011, at 11:23 AM, Dennis Hübner wrote:
> Hudson links aka
> file:/opt/users/hudsonbuild/.hudson/jobs/MWE-nightly-HEAD/lastSuccessful/archive/mwe.p2.repository/
> doesn't work e
Hudson links aka
file:/opt/users/hudsonbuild/.hudson/jobs/MWE-nightly-HEAD/lastSuccessful/archive/mwe.p2.repository/
doesn't work either
Means we can't fetch latest artifacts from jobs we depend on.
Regards,
Dennis.
Am 07.12.11 10:58, schrieb Dennis Hübner:
> Hello Matt,
> I'm not quite sure that
Hello Matt,
I'm not quite sure that my issue is related to the latest changes, but
I just noticed that our lastSuccessful/lastStable file system links a
not up to date.
Hudson web link
https://hudson.eclipse.org/hudson/job/MWE-nightly-HEAD/lastStableBuild/
points to 07.12.2011 build
and file system
19 matches
Mail list logo
