Re: [cross-project-issues-dev] restarting sandbox hudson

2013-06-10 Thread Matthias Sohn 
On Mon, Jun 10, 2013 at 8:28 AM, Mickael Istria  wrote:

>  On 06/10/2013 08:25 AM, Matthias Sohn wrote:
>
> Since sandbox hudson emits Bad Gateway errors in random situations I am
> going to restart it hoping this will fix these problems.
>
> Hi Matthias,
>
> You should first have a look at this issue:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=410271 .
> If you need some free space, feel free to remove all builds from
> SWTBot-Gerrit and SWTBot-Sonar jobs (except the last successful one). Not
> sure it will be enough though.
>

I restarted sandbox Hudson but still the egit.gerrit job faile with a "Bad
Gateway" error
(https://hudson.eclipse.org/sandbox/job/egit.gerrit/4622/console):

Caused by: org.apache.maven.wagon.TransferFailedException: Failed to
transfer file: 
http://repo.maven.apache.org/maven2/org/codehaus/gmaven/feature/gmaven-feature-support/1.4/gmaven-feature-support-1.4.jar.
Return code is: 502, ReasonPhrase:Bad Gateway.
at 
org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:852)
at 
org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
at 
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:601)
... 4 more


Then I configured the SWTBot-Gerrit and SWTBot-Sonar jobs to only keep the
artifacts
of the last succeeded build which freed some diskspace. It seems this
helped to enable
the egit.gerrit job to run successfully again.

Looking at current disk usage at
https://hudson.eclipse.org/sandbox/plugin/disk-usage/
there are a couple of jobs consuming quite a lot of disk space for their
workspaces,
maybe some of them could free some space. I'd recommend they all configure
their
jobs to only retain the artifacts of the last successful build.

Probably a large fraction of this space is consumed by job-private maven
repositories.
Not sure if there is a way to get rid of the need to use private maven
repositories,
AFAIK this is needed since sharing local maven repositories between
multiple jobs
doesn't work reliably.

Overall it looks like sandbox Hudson needs more HDD resources.

 Disk usage*Builds:*4GB, *Workspace:*33GB

Project name
BuildsWorkspace
  ↑ 
*platform-sonar
*68MB7GB*target-management
*144MB2GB*linuxtools *
1GB2GB*linuxtools-sonar
*88MB1GB*mylyn-context-mft-gerrit
*878KB1GB*mylyn-context-gerrit
*2MB1GB*mylyn-reviews-gerrit
*16MB1GB*mylyn-tasks-gerrit
*152MB1GB*xtext.gerrit
*703MB1GB*mylyn-docs-gerrit
*14MB964MB*epp-mpc-gerrit
*11MB963MB*mylyn-commons-gerrit
*72MB805MB*e4-tools *60MB
744MB*GMF-Tooling-Sonar
*540MB725MB*mylyn-builds-gerrit
*1MB718MB*emf-compare.gerrit
*3MB710MB*recommenders.gerrit-e3x
*26MB700MB*recommenders.gerrit
*29MB678MB*mylyn-versions-gerrit
*521KB667MB*tcf.gerrit *
26MB583MB*mylyn-reviews-r4e-gerrit
*22MB570MB*koneki-ldt-sonar
*49MB556MB*vjet-juno-sonar
*239MB552MB*emfstore-sonar
*56MB542MB*eclipse.scout.sdk
*29MB507MB

--
Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] restarting sandbox hudson

2013-06-10 Thread Mickael Istria 

On 06/10/2013 09:23 AM, Matthias Sohn wrote:
Looking at current disk usage at 
https://hudson.eclipse.org/sandbox/plugin/disk-usage/
there are a couple of jobs consuming quite a lot of disk space for 
their workspaces,
maybe some of them could free some space. I'd recommend they all 
configure their

jobs to only retain the artifacts of the last successful build.
I cleaned some other jobs to keep only the 3 last builds 
(GMF-Tooling-Sonar, Nebula-sonar, Nebula-incubation-sonar), it should 
save a few hundreds megs.
Just after, I re-triggered the platform-sonar job ;) I'm crossing 
fingers to see it going to the end without filling all the free space.


Probably a large fraction of this space is consumed by job-private 
maven repositories.
Not sure if there is a way to get rid of the need to use private maven 
repositories,
AFAIK this is needed since sharing local maven repositories between 
multiple jobs

doesn't work reliably.
Yes, private repositories seem necessary to ensure no side-effects 
between jobs and because Maven repository doesn't accept well concurrent 
modifications.



Overall it looks like sandbox Hudson needs more HDD resources.

Yup.

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat 
My blog  - My Tweets 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] restarting sandbox hudson

2013-06-10 Thread Mickael Istria 
Oops!... I broke it again. 
https://hudson.eclipse.org/sandbox/job/platform-sonar/7/console
If one needs to restart Hudson sandbox, feel free to delete that 
platform-sonar workspace as it looks like it definitely can't run while 
Hudson-sandbox does not get bigger HDD.


Sorry for the inconvenience !
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat 
My blog  - My Tweets 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] restarting sandbox hudson

2013-06-10 Thread Matthias Sohn 
On Mon, Jun 10, 2013 at 2:00 PM, Mickael Istria  wrote:

>  Oops!... I broke it again.
> https://hudson.eclipse.org/sandbox/job/platform-sonar/7/console
> If one needs to restart Hudson sandbox, feel free to delete that
> platform-sonar workspace as it looks like it definitely can't run while
> Hudson-sandbox does not get bigger HDD.
>

thanks, I deleted this workspace and it seems this helped, some verification
jobs seem to be able to run again.

--
Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Missing release information for some Kepler projects

2013-06-10 Thread John Arthorne 
I recall the planning council recently decided on a policy that we would 
not allow a new release of a project to appear for the first time after 
RC1. Am I remembering that incorrectly? This is exactly the kind of last 
minute change that caused trouble for the release train in Juno SR2. I 
think at this point they should be contributing the same release that was 
contributed in RC1, which sounds like 4.0.

John



From:   David M Williams 
To: Cross project issues , 
Date:   06/07/2013 09:52 AM
Subject:Re: [cross-project-issues-dev] Missing release information 
for some Kepler projects
Sent by:cross-project-issues-dev-boun...@eclipse.org



I agree its "not cool". I do not know their reasons for it. I do recall 
them sending a note a month or two ago "asking for preferences" ... so 
suggest you and DLTK project work out which is best (for you to move to 
5.x or them to revert to 4.x). There should only be one version major 
version in the common repository. 

Good luck, 




From:Benjamin Cabé  
To:Cross project issues , 
Date:06/07/2013 09:40 AM 
Subject:Re: [cross-project-issues-dev] Missing release information 
for some Kepler projects 
Sent by:cross-project-issues-dev-boun...@eclipse.org 



Hi, 

Contributing DLTK 5.0 and removing 4.0 at the very last minute (RC3) to 
the Kepler repo with no previous contribution before that would have 
allowed Koneki Lua Development Tools to be tested against it, is not 
really cool to say the least. LDT contribution to Kepler is now broken. 
Any chance to also include DLTK 4.0 into the Kepler repo? 

Thanks. 
Benjamin-- 


De : Alexey Panchenko 
Répondre à : Cross project issues 
Date : jeudi 9 mai 2013 17:49
À : Cross project issues 
Objet : Re: [cross-project-issues-dev] Missing release information for 
some Kepler projects 

Hi, 

Unfortunately The DLTK team were quite busy this year with other projects. 
Initially the previous (4.0, released 2012) version was added to Kepler, 
with the intent to replace it later with the 5.0 builds from master. So 
far, that did not happen yet, partly because of source control (-> git) & 
build system (-> tycho) changes. 

AFAIK DLTK is used by PDT and Koneki-Lua Development Tools. 
So the question to these projects: what DLTK version would you prefer in 
Kepler? 

Regards, 
Alex 


On Thu, May 9, 2013 at 12:26 AM, Wayne Beaton  wrote: 
I am now only missing the information for the DLTK and Runtime Packaging 
(RTP) project. I have contacted DLTK via their mailing list; Ian has 
contacted the RTP project leaders directly (thanks, Ian).

I noticed that DLTK is contributing their 4.0 release build (from Juno) to 
Kepler, despite there being some apparent activity in the project Git 
repositories. I don't know if there is any specific issue with this, but 
thought that I'd point it out in case any downstream consumers had any 
concerns/issues.

Thanks, 


Wayne

On 04/26/2013 02:38 PM, Wayne Beaton wrote: 
I am missing release information for the following projects that have 
declared intent to participate in Kepler.

C/C++ Development Tools (CDT)
Dynamic Languages Toolkit (DLTK)
Eclipse Modeling Framework (EMF)
Eclipse Communication Framework (ECF)
Runtime Packaging Project (RTP)
EclipseLink
Ecore Tools
Extended Editing Framework (EEF)
Jubula Functional Testing Tool
MDT XSD (XML Schema Definition)
Maven Integration for Web Tools Platform
SCA Tools

In some cases, it may be that I just can't sort out what release you want 
to include, or maybe you're planning to include a release that does not 
occur on the Kepler release date (which I find weird, but is otherwise 
okay). 

If you have not done so already, please visit your project's information 
page and create a release record for Kepler and then please let me know 
either on this list or via direct email so that I can update the Kepler 
release page.

I will not accept review documentation for any release that is not 
recorded in the project metadata.

While you're there, please take a few minutes to update the description 
and plan information for your release. The description should be a  short 
paragraph that concisely describes the high points of the release. Note 
that you can still use the old XML-file based plan format if you like 
using old and painful technology.

You can quickly get access to your project's information page directly 
from the Kepler release page:

https://projects.eclipse.org/releases/kepler

Let me know if you require any assistance.

Wayne 
-- 
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects



 _ __
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 

-- 
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects


_ __
cross