| I managed to create a prototype for equinox launcher (gtk.linux.x86_64). It runs on the centos slave. The job is located here https://hudson.eclipse.org/cbi/view/natives/job/cbi-launcher-linux-x86_64/. Anyone can see the configuration in readonly mode (https://hudson.eclipse.org/cbi/view/natives/job/cbi-launcher-linux-x86_64/configure).
Thanks. Mikael
> Other archs will be provided by third parties. Instead of just
> committing the binaries in the binary repo, the idea is to connect
> the machines to the master hudson. It will let anyone with access to
> the Hudson master see the third parties build logs for transparency
> and it will also let the Hudson master triggers other archs builds
> when sync is needed. The third party slaves don't even need to have
> commit rights to the binary repo, this can be done by Hudson master.
> The main issue is that third parties must make their machine run a
> sshd visible to the internet.I'm not sure I understand the need, or point of this part of the process. AND, while I have no first-hand knowledge, I think having a 3rd party build machine "visible to the internet" would be a non-starter for many 3rd parties (or ... a least a pretty big hurdle). I wonder if the transparency could be achieved by simply having the requirement that "logs and configs" must be supplied too, along with the binary? And, then the third party could push them both to Git using current, more familiar mechanisms? (And the logs and and configs being checked into Git seems like a good idea in any case, for long term reproducibility of even those = == = => What about using git branches to sync up builds? Today, all binaries
> are committed in a single commit and then tagged, and that make the
> sync quite obvious. What about using a git branch where all the
> platform binaries will be committed? The branch will match a commit
> in the source git repo and will then be the unit of synchronization.This idea is definitely worth considering. And, to add a small twist perhaps submodules could also be used, for each target environment? I've heard the most recent versions of Git allow you to "track submodules" by branch, and not merely "commit hash". That might be an easy way to "include submodules in the build that are in a branch XYZ" (or, recursively, a submodule of it) and skip the rest? The commit of the "parent module" would supply the "fragment version" (if that's still needed) and the commits of the submodule branches would simply be recorded by the build, for reproducibility. Just a loose idea, at this point. [And, I am aware at phone meeting we said we didn't want a different repository for each contribution, but I think that's nearly transparent, if using recursive submodules]. From: Mikael Barbero <mikael@xxxxxxxxxxx>To: Common-build Developers discussion <cbi-dev@xxxxxxxxxxx>, Date: 08/21/2015 04:09 AMSubject: Re: [cbi-dev] Summary for conf call for having native parts builds moved to eclipse.org infraSent by: cbi-dev-bounces@xxxxxxxxxxx
It seems that Mail.app pasted pictures is not compatible with every mail reader. Here are the pictures in png formatThe way things are committed to git repos.<Pièce jointe.png>The hudson proposed infra<Pièce jointe.png>Le 21 août 2015 à 09:56, Mikael Barbero <mikael@xxxxxxxxxxx> a écrit :Alex, thanks for the good summary.Comments below.Le 20 août 2015 à 17:50, Aleksandar Kurtakov <akurtako@xxxxxxxxxx> a écrit :Eclipse.orginfra is heading towards providing infra for rebuilding the native parts of Eclipse platform for Win, Mac, Linux x86_64 (x86?). There are more parts that contain native code but the two crucial parts are SWT and Equinox Launcher so work starting on themhat about us. For simplicity the first ws/os/arch combo to be worked on will gtk.linux.x86_64.
Current native build scripts are monolithic in terms of one platform failing to builds leads to none recieving rebuilt native library. New approach will be that whatever platform succeeds in rebuild is committed and the rest will be let to fail during the aggregation or tests run. Natives not done @eclipse.org(rest of ws/os/arch combos produced currently) will be contributed by member companies and it will be their duty to sync up builds. N-builds and I-builds might have some different requirements for synchronization. Build will be done in Hudson with one job per platform, build with Maven - `mvn clean verify -Dnative=ws.os.arch` to open the door for simplifying the build script and hudson will commit to the git repo (noone objected). What about version bumps/tags/etc.? Don't remember being discussed. What about using git branches to sync up builds? Today, all binaries are committed in a single commit and then tagged, and that make the sync quite obvious. What about using a git branch where all the platform binaries will be committed? The branch will match a commit in the source git repo and will then be the unit of synchronization. Picture is worth a thousand words so:<PastedGraphic-1.tiff>A proposal for contributing a remote machine maintained at member company but being attached as Hudson slave for doing the build for additional platforms was done by Mikael not much interest in it now (Mikael, please ellaborate).The idea behind this proposal is to avoid having builds being contributed to the binary repo "out of nowhere". The way things will be done: an architecture will be build on a dedicated slave. The Eclipse Foundation commitment is about the three main platforms (linux, windows and macosx) in their respective 32/64 bits variants. Other archs will be provided by third parties. Instead of just committing the binaries in the binary repo, the idea is to connect the machines to the master hudson. It will let anyone with access to the Hudson master see the third parties build logs for transparency and it will also let the Hudson master triggers other archs builds when sync is needed. The third party slaves don't even need to have commit rights to the binary repo, this can be done by Hudson master. The main issue is that third parties must make their machine run a sshd visible to the internet. Again, a picture is worth... :<PastedGraphic-2.tiff>Initial work plan is:
1. Duplicate platform repos in cbi for swt.binaries, equinox.binaries and releng.aggregator (to make submodules point to cbi swt.binaries, equinox.binaries repos).
2. Get slaves for build machines - RHEL being a blocker for the initial work, Mac/Win to open paralel fronts
3. Have builds running on this slaves - Most things available now, only big missing thing is Xulrunner AFAIK.
4. Get hudson committing to the cbi git repos on successful builds
5. Run aggregation job - it would produce all the tarballs/zips but only the one targetted will be expected.
6. Find some comparator tool and run it against zip produced by this new build and the old way produced one to find potential differences.Sounds like a plan. I will duplicate git repo mentioned above in cbi today. Thanks.Mikael_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cbi-dev_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cbi-dev_______________________________________________cbi-dev mailing listcbi-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/cbi-dev
|
