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,

I looked at things -- it seems like we already have a location for Nightly builds:

http://build.eclipse.org/technology/babel/

On the Hudson servers, that translates to the local filesystem: /shared/technology/babel

That location is already writable directly by Hudson, and it is obviously web accessible, and is suitable for hosting Nightly builds.  Go ahead and configure your Hudson Nightly job to publish build artifacts to, say, /shared/technology/babel/tools-updates-nightly instead of /home/data/httpd/download.eclipse.org/technology/babel/tools-updates-nightly


By all means, do sign your nightly builds.  I just thought you didn't want to get into signing just yet.

Keep the questions coming  :)



Denis



On 12/17/2012 01:30 AM, Stefan Strobl wrote:
Hi

thx for the feedback and creating the directories.

I have requested the new hudson job and the changes to the old one:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=396704

Just to make sure I understand, you are basically suggesting the following path:
* nightly build: publishes unsigned artifacts to a temp directory from where a cron job will copy them to the downloads directory
* release build: will be used for release builds only which will be signed and manually (?) published to a seperate downloads directory (to be created)

Any reason why we should not sign the nightly builds? To expensive?

regards,
Stefan

On 13.12.2012 22:14, Denis Roy wrote:
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