Bugzilla – Full Text Bug Listing
| Summary: | Hudson Job for AMP | ||
|---|---|---|---|
| Product: | Community | Reporter: | Miles Parker <milesparker> |
| Component: | CI-Jenkins | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | milesparker, nboldt, webmaster |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Miles Parker
Jobs can be renamed. The only reason to have "0.2" / "0.5" or "Galileo" / "Helios" is if you have two streams building concurrently, like Eclipse Galileo maintenance and Helios integration. If you don't plan to have concurrent builds, then cbi-amp-nightly is fine. Are you the only committer on the AMP project? Where in CVS/SVN is your .releng project? I can link to it directly or I can leave TODO/FIXME markers in the Hudson config and you can set it up yourself, once the job's created and you've got access. (In reply to comment #1) > If you don't plan to have concurrent builds, then cbi-amp-nightly is fine. Makes sense. I think I read that M and R builds are just constructed by temporarily changing properties of an existing hudson N build. > Are you the only committer on the AMP project? Where in CVS/SVN is your .releng > project? I can link to it directly or I can leave TODO/FIXME markers in the > Hudson config and you can set it up yourself, once the job's created and you've > got access. Yes, unfortunately. :) /cvsroot/modeling/org.eclipse.amp/releng/org.eclipse.amp.releng. I doubt it will run OOTB.. If it works locally, it should work in Hudson - provided that the JAVA*_HOME variables are set correctly for build.eclipse.org's paths. And yes, if you want to manually spin a milestone you can set EXTRAFLAGS to "-buildAlias 0.5.0M4", and BUILDTYPE to S (stable). https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-amp-nightly/ Looks like your build.properties file has CVS conflict markers in it; the build might fail because of that. https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-amp-nightly/ws/build/N200909081517/build.cfg Search for "<<<<<<<" or "=======" and clean up those unwanted lines. Thanks Nick. Yes, you've caught me mid-stream shuttling things back and forth between machines. And thanks for pointing out the JAVA_HOME I'll need to fix that as well. Nick, I can't see the "build now" button. And when I try https://build.eclipse.org/hudson/job/cbi-amp-nightly/ I get and access denied. Whoops, just saw reference to.. https://bugs.eclipse.org/bugs/show_bug.cgi?id=257265#c34 I'll take a look. OK, that one didn't apply to me as I'm only a lowly commoner. :) So it looks like someone needs to https://build.eclipse.org/hudson/job/cbi-amp-nightly/configure and open project based permissions to me? (In reply to comment #9) > like someone needs to open project based permissions to me? Already done when I created the job. Have you tried logging in? https://build.eclipse.org/hudson/login?from=https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-amp-nightly/ Maybe there's something wrong w/ your LDAP entry...? (In reply to comment #10) > (In reply to comment #9) > > like someone needs to open project based permissions to me? > > Already done when I created the job. I assumed that you had, but it's not working. > Have you tried logging in? Yep. ;) I should have given more detail. I can log in but I can't access configure from the job. > https://build.eclipse.org/hudson/login?from=https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-amp-nightly/ > > Maybe there's something wrong w/ your LDAP entry...? Um...I'm embarrassed to say that I don't know what you're talking about. :) I checked my id on build.eclipse.org and I'm a member of modeling.amp; perhaps there is a mismatch with the group for the build? (In reply to comment #11) > > Have you tried logging in? > Yep. ;) I should have given more detail. I can log in but I can't access > configure from the job. > > Maybe there's something wrong w/ your LDAP entry...? Webmasters, over to you. Something's preventing 'mparker' from configuring a job in Hudson which has 'mparker' set as one of the authorized users. Noteworthy too, the icons that normally appear in the "Enable project security" section of the job next to the individual user/group entries take much longer to appear than they used to. Could that be related? (In reply to comment #5) > Thanks Nick. Yes, you've caught me mid-stream shuttling things back and forth > between machines. And thanks for pointing out the JAVA_HOME I'll need to fix > that as well. Build actually did ok, but for this: Missing required plug-in org.eclipse.gef3d.ext_0.0.0. Of course that's before compilation happens, so the possible JAVA*_HOME issue is masked by that. Note that there's a /opt/public/cbi/build/3rdPartyJars folder in which you can store zips you need for your build. Put it somewhere on build.eclipse.org and I can copy it there. You can then refer to it like this in your dependencyURLs configuration (build.properties file): http://build.eclipse.org/cbi/build/3rdPartyJars/<zipname>.zip Provided the SDK/runtime zip contains eclipse/plugins/*.jar and/or eclipse/features/, it'll unpack it into dropins/ and be available when building AMP. (If it's an update site zip, put "Update" in the filename and it'll be unpacked and installed correctly.) (In reply to comment #13) > Build actually did ok, but for this: > > Missing required plug-in org.eclipse.gef3d.ext_0.0.0. > > Of course that's before compilation happens, so the possible JAVA*_HOME issue > is masked by that. Yeah, that's because I bundled the gef3d zip up incorrectly -- exactly as I had warned about in my blog entry. It's tough when your compile-edit-debug loop is six hours long. ;) > Note that there's a /opt/public/cbi/build/3rdPartyJars folder in which you can > store zips you need for your build. Put it somewhere on build.eclipse.org and I > can copy it there. You can then refer to it like this in your dependencyURLs > configuration (build.properties file): > > http://build.eclipse.org/cbi/build/3rdPartyJars/<zipname>.zip > > Provided the SDK/runtime zip contains eclipse/plugins/*.jar and/or > eclipse/features/, it'll unpack it into dropins/ and be available when building > AMP. (If it's an update site zip, put "Update" in the filename and it'll be > unpacked and installed correctly.) Wow, that's cool. But what's the advantage of doing that vs. using the dependency URL? Are those not cached? (In reply to comment #14) > > Note that there's a /opt/public/cbi/build/3rdPartyJars folder in which you > Wow, that's cool. But what's the advantage of doing that vs. using the > dependency URL? Are those not cached? Two reasons: a) you can put stuff in there that's not necessarily EPL-friendly / CQ-approved and it's more obvious that it needs to be treated as "build runtime environment only, not for distribution". Net4J/CDO use this space for mysql stuff which they need for compilation, but do not ship (for license reasons, they cannot ship it from eclipse.org). b) it's outside the Hudson workspace so if you ever need to blow away your workspace and start fresh, you won't need to re-download the zip (like you would with all the dependencyURLs or p2.director-installed features/plugins sourced from remote update sites). More pervasive storage for faster builds / bandwidth optimization. (In reply to comment #15) > (In reply to comment #14) > > > Note that there's a /opt/public/cbi/build/3rdPartyJars folder in which you > Wow, that's cool. > a) you can put stuff in there that's not necessarily EPL-friendly / CQ-approved > and it's more obvious that it needs to be treated as "build runtime environment > only, not for distribution". Net4J/CDO use this space for mysql stuff which > they need for compilation, but do not ship (for license reasons, they cannot > ship it from eclipse.org). Yeah, that makes a lot of sense. I was actually about to check into any requirements WRT to CQ on the build side. I obviously wasn't planning to actually bundle anything into the What I'd really like to do is use the LWJGL (Apache CL) update site site directly but I haven't been able to figure that one out yet. > b) it's outside the Hudson workspace so if you ever need to blow away your > workspace and start fresh, you won't need to re-download the zip (like you > would with all the dependencyURLs or p2.director-installed features/plugins > sourced from remote update sites). More pervasive storage for faster builds / > bandwidth optimization. Right, so essentially you've got the Giga pipe for eclipse hosted downloads but anything else not. And given the performance of say sourceforge that could make a difference. On the web permissions stuff, is there somewhere/someone else I should perhaps alert? (In reply to comment #13) > > Provided the SDK/runtime zip contains eclipse/plugins/*.jar and/or > eclipse/features/, it'll unpack it into dropins/ and be available when building > AMP. (If it's an update site zip, put "Update" in the filename and it'll be > unpacked and installed correctly.) Sorry to spam, but I was thinking of one potential downside. Unless I'm missing something 3rdPartyJars would be the one thing that the build would not be able to reconstruct completely. Perhaps it would make sense to put this into one's project.releng project, but then you have the issue of putting non CQ'd resources into Eclipse CVS. (In reply to comment #17) > Sorry to spam, but I was thinking of one potential downside. Unless I'm missing > something 3rdPartyJars would be the one thing that the build would not be able > to reconstruct completely. Perhaps it would make sense to put this into one's > project.releng project, but then you have the issue of putting non CQ'd > resources into Eclipse CVS. Correct. The tradeoff is speed/bandwidth. Either you fetch everything from scratch every time, or you cache some things locally, like you did with GEF3D on your own box. As to putting non-CQ'd stuff into your foo.releng, I advise against that, esp. since this bug is cc:'d to the webmasters. If there's one thing the @eclipse.org people take seriously, it's IP policy. (There are lots of things, obviously, but IP is very high on the list.) (In reply to comment #18) > As to putting non-CQ'd stuff into your foo.releng, I advise against that, esp. > since this bug is cc:'d to the webmasters. If there's one thing the > @eclipse.org people take seriously, it's IP policy. (There are lots of things, > obviously, but IP is very high on the list.) Yes, by the issue, I should have said "THE ISSUE" and added lots of little winkies. It is an interesting intersection of IP and build issues. OK, one final issue w/ testing I think. My acore.edit tests need to run as Plugin JUnit tests, i.e. that's how they have to be invoked on local machine. (They exercise a bunch of EMF interactions and have to load resources as if they were in user environment.) I was thinking that the JUnit tests on Hudson were essentially plugin tests, but is that not the case? If not is there a way to accomplish something similar? I resolved the testing issue. It was actually something on my end where I was referring to a file that is only accesible when plugin projects are unzipped. Changing it to use EMF delegate URL instead worked. And we are green! Thanks for all your help, Nick. I'll send you an email as well, but go ahead and back off on the check frequency. The hudson permission issue is still open -- I've been working with webmaster(s) on that via email. The permissions issue has been resolved as well. I'm going to resolve as fixed, hope that's to protocol. |