Best strategy for multi-config library project?

classic Classic list List threaded Threaded
4 messages Options
Eno
Reply | Threaded
Open this post in threaded view
|

Best strategy for multi-config library project?

Eno
I have a project which produces a library that needs to be copied into another project to build an application. Its complicated by the fact that I need to build X versions of this library, and each one needs to produce a separate build of the main application.

I created a job to build the library using a configuration matrix. It successfully builds X versions of the library and I have it archiving each version of the library.

Not quite sure how to proceed from here - I guess I need to create a build that pulls these archived files into the application tree and build the application. Would be nice if I could use somehow use the axes values to name the package when I copy it across to staging area. Not sure how to do these last two pieces.


Reply | Threaded
Open this post in threaded view
|

Re: Best strategy for multi-config library project?

Sami Tikka
Read http://wiki.hudson-ci.org/display/HUDSON/Splitting+a+big+job+into+smaller+jobs

You probably need to create a matrix job that builds the X versions of
the applications.

Unfortunately you cannot re-use the configuration matrix of the
library job in the application job.

Your application build script can download the library artifacts using
the permalinks you can find on the library job's Hudson page. The
download can be done using wget or curl or URL SCM plugin or Copy
artifact plugin.

-- Sami

2010/7/29 Eno <[hidden email]>:

>
> I have a project which produces a library that needs to be copied into
> another project to build an application. Its complicated by the fact that I
> need to build X versions of this library, and each one needs to produce a
> separate build of the main application.
>
> I created a job to build the library using a configuration matrix. It
> successfully builds X versions of the library and I have it archiving each
> version of the library.
>
> Not quite sure how to proceed from here - I guess I need to create a build
> that pulls these archived files into the application tree and build the
> application. Would be nice if I could use somehow use the axes values to
> name the package when I copy it across to staging area. Not sure how to do
> these last two pieces.
>
>
>
> --
> View this message in context: http://hudson.361315.n4.nabble.com/Best-strategy-for-multi-config-library-project-tp2306908p2306908.html
> Sent from the Hudson users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Eno
Reply | Threaded
Open this post in threaded view
|

Re: Best strategy for multi-config library project?

Eno
Yeah, I figured that the downstream package would have to have its own separate matrix.

In my library build, I copy each library to a folder with the matrix value as the folder name at the end of its build, then I have it trigger my main application build which also uses a matrix with the same values. The main build copies the library into its workspace before doing a normal build afterwards copying the final package out to the same folder as the library.

It all works very well.

The only issue is that an update in matrix values will need to be updated on the downstream project first and then the upstream, and both need to be kept in sync.

I noticed the build happen in parallel with matrix builds, and usually in pairs, is there a setting that governs the number of simultaneous builds?
Eno
Reply | Threaded
Open this post in threaded view
|

Re: Best strategy for multi-config library project?

Eno
Never mind, I just noticed the number of executors setting in the main Hudson configuration.