Community
Participate
Working Groups
I'll use this bug to track issues (even if just documenting "how to" for getting "head builds" working for 4.2 primary builds on build.eclipse.org. Naturally, we'll set "builtType" to N, but .... not sure if there might have to be other changes? (Ideally not, but ... I'd be amazed :)
This will soon be getting my attention. Just to clarify, are N builds normally "signed"? I know there is merit to "making each build as complete and realistic as can be", but ... there are resource limits. And signing is so "expensive" and N builds basically "throw away" that my initial plan is to not sign them. Do let me know if anyone feels strongly about this.
(In reply to comment #1) > This will soon be getting my attention. > > Just to clarify, are N builds normally "signed"? So far we didn't sign them and I think we can keep it that way.
Yes we don't sign N-builds and that's fine.
N20120415-2015 looks good, but it is missing our latest JDT and PDE doc changes. We need to find a good solution here. With "good" I mean one where we don't have to do every commit to two branches. I see two possible solutions: a) Improve the builder so that it can create a build out of two different branches of a repo. repositories.txt would then also allow to specify the project/folder name. b) Split the common repo.
Thanks Dani, just do document some of the "mechanics" These are working well enough I've set a cron job for every night at 8 PM. Without signing, and with no tests, only take a little over an hour to complete. the build is essentially invoked with masterBuild.sh -buildType N -eclipseStream 4.2 -buildRoot $buildRoot -mapVersionTag R4_HEAD codified in a file named mb4N.sh in the scripts directory. The "promote to downloads" is not fully automated, but comes down to running a script after the build, that invokes other scripts to a) update N repository on downloads, b) copy to build to "downloads" 'drop4' directory, c) update the index.html file so it includes the new build, and d) send a mail to platfrom-releng-dev list. There's a couple of ways to automate that the last step ... I'll sort that out this week, but otherwise, will just "run the command" myself around 10 PM for a few nights. I'll leave this open until fully automated and/or until the doc issue/common repo issue is sorted out. (BTW, my off hand preference would be its better to have the docs in separate repos (platform, jdt, pde), so could be well associated with the project it goes with (though, I know couldn't be exactly the same repo, from what I've heard, that'd be hard to fix up) ... but ... I'm sure others would know best).
> (BTW, my off hand preference would be its better to have the docs in separate > repos (platform, jdt, pde), so could be well associated with the project it > goes with (though, I know couldn't be exactly the same repo, from what I've > heard, that'd be hard to fix up) ... but ... I'm sure others would know best). I guess I would not add a PDE and JDT repository but rather a common.3x repo. We can use bug 362032 for further discussions.
I had a quick can of the build, and noticed a minor discrepancy with the branding plugins, the qualifier doesn't match the nightly N20120415-2015. ex: org.eclipse.platform_4.2.0.v20120415-2018 A quick scan of a regular nightly from a while ago for N20110712-2000 reveals: org.eclipse.platform_3.7.0.v201107122000 Probably not worth tracking down those 3 minutes :-) PW
I think this general bug can be marked "fixed" and future improvements can be handled in other bugs.
