[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bpel-dev] Update sites and Builds
- From: Vincent Zurczak <vincent.zurczak@xxxxxxxxxxxxxx>
- Date: Tue, 17 Apr 2012 19:14:38 +0200
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
Le 17/04/2012 16:08, Bob Brodt a Ãcrit :
I've been poking around on build.eclipse.org (via ssh) trying to figure out where all of the bpel bits live. It looks like the hudson build artifacts are going to /opt/public/soa/bpel/0.8.0 and /opt/public/soa/bpel/juno.
Yes, this is where we move the build results.
Not all the build results, only those of the Juno job.
We take the created update site, we pack and sign it, and then we
archive it there.
The Helios job (bpel-0.5) is only used to check the compatibility
between the code and Helios.
There are also bpel artifacts on /shared/jobs/bpel-0.5 and /shared/jobs/bpel-juno.
That must be Hudson's working directories for our jobs.
Finally the public update sites are in /home/data/httpd/download.eclipse.org/bpel/site and this is where I've been publishing the stuff from /shared/jobs/bpel-0.5 manually after a successful build.
This is the promotion place.
When we have a build we consider as valid, we should move it from
/opt/public/soa/bpel/... to the download part.
What we could also do, is to directly push the build results on
In that case, we would have sub-directories for versions (0.8, 1.0, etc).
That was my questions last time.
By the way, I still have to ask to rename the Hudson job bpel-0.5 into
I will also ask to remove /opt/public/soa/bpel/juno, since we now use
the version in the directory name.
RCP Developer & ESB Consultant
Petals Link: http://www.petalslink.com
My Blog: http://vzurczak.wordpress.com
+33 (0) 4 76 96 15 16