Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [babel-dev] Build configuration for babel plugins

Hi Stefan,

Good to see you're making rapid progress.

Some input, below:

On 12/10/2012 03:50 AM, Stefan Strobl wrote:
Hi

short update: I just pushed my changes and the CI build is still green [0] ;) so we're good for now:

Next Steps:
* If anyone with experience in using the eclipse-signing-maven-plugin could review the changes [1] I would be really greatful (thx to Martin for the initial review)
* Decision on Hudson Jobs: currently we have one job [2] which is configured for continuous integration (e.g. building more or less after every build). I do not think that signing and publishing the results is good/necessary to do so often. The question therefore is: do we change the current build to a "nightly" build or should I request a new one?
I suggest changing the current job name to *nightly and creating a new *release job (which would (eventually) perform signing).


* create directories as described below
I've created /home/data/httpd/download-staging.priv/technology/babel and it is directly writable by Hudson.
I've also created /home/data/httpd/download.eclipse.org/technology/babel/tools-updates-nightly .. it is not writable by Hudson. 


Denis



Hi

Matthias, first of, thanks a lot for the pointers. Having a project to "steal" most of the setup from really makes this job quite a bit easier. Btw: I spent most of my time figuring out how to produce a suitable category.xml file. From what I understand, and I learnt today that I still understand very little ;), this basically does all the steps that Denis described in his previous post (creating a p2 repo, etc..)

I got around to playing with the eclipse-signing-maven-plugin today and I think, I have a working version locally. I'm going to let Martin review my changes and wait for the answers to my question below before pushing to the babel repo though.

@Denis, Matthias: it seems that egit copies the repository directly to the downloads section (/home/data/httpd/download.eclipse.org/...), correct?
@Denis: you mentioned that the webmasters are not so happy about this approach. If it is ok with you I would still like to take the direct route first to test the setup etc and then subsequently introduce the cron job, once everything is working.

currently, I would use the following two directories:
* temp location for signing: /home/data/httpd/download-staging.priv/technology/babel
* destination for singed p2 repository: /home/data/httpd/download.eclipse.org/technology/babel/tools-updates-nightly

If these directories are ok, I will create them on build.eclipse.org (I just tested, unblocked and used my shell access ;) ) and then push my changes and test them on the server with hudson.

Cheers
Stefan

On 28.11.2012 23:21, Matthias Sohn wrote:
2012/11/28 Stefan Strobl <stefan.strobl@xxxxxxxxxxxxxxxxx>
Hi

Denis, thank you very much for this valuable and extensive feedback!

to all: I'd volunteer to take a look at step a), which, as I understand it, is independent from the remaining parts. I won't get to it until mid next week though, please let me know if that is a problem...

and, getting ahead a little - concerning d): Maybe it would be a good idea to split the download page for tools and translations?

we are using the eclipse-signing-maven-plugin [1] to sign jgit and egit bundles.
Have a look at egit's org.eclipse.egit.repository project [2] generating the p2 repository.
You can use that as an example how to generate a p2 repository and how to sign all its
content. Some of the properties used in that pom.xml are defined in egit's parent pom.xml [3].
In order to use the signing plugin we enable the maven profile "build-server", this only
works on Hudson (or build.eclipse.org) since the signing infrastructure can't be used
from outside Eclipse foundation infrastructure for security reasons.

Have a look at Tycho's reference documentation for additional details on how to
generate p2 repositories [4].


-- 



Back to the top