[csw-maintainers] Hudson

[Trygve Laugstøl]

Dagobert Michelsen wrote:
> Hi,
> 
> Am 29.11.2008 um 18:16 schrieb Trygve Laugstøl:
>>> As you can see the packages are put in /local/hudson/gar/pkgs. What I
>>> would like to do now is to get Hudson to put all of those packages  
>>> to a
>>> NFS share, run a job to create a catalog and then export that to our
>>> consumers.
> 
> Good idea! Linked to
>    <http://mirror.opencsw.org/opencsw/hudson/>
> 
> About setting up projects: Here is an idea of how to deal
> with releases in the future.
> - 'gmake release' checks that everything is committed to the
>    repository and makes a copy to tags/<pkg>-x.y,REV=a.b.c

This is most likely very useful and something that we should work on.

> - Hudson makes packages from tags/* with the revision stamp

This might be a bit more pain than what we gain from it. You would have 
to create a new job for Hudson to build from a tag which would be used 
only once.

I would rather create a script that

  1) checks out the code
  2) performs gmake clean package to create the package
  3) tags the package
  4) copies the pkg.gz to new/

> - The URL and SVN revision are annotated inside the package
>    This makes it possible to exactly reproduce any package and
>    reference the build description precisely
> - Only packages generated in this way will be accepted for
>    release in the future
> - This way it will be possible to allow "fast-tracking" of
>    emergency bugfixes as the packages could be delivered
>    and catalog build automatically. The details still need
>    to be worked out of course.
> - Packages from trunk/ and branches/ are also build by Hudson
>    but are put in another location (continoues integration)
>    (/opencsw/testing/<maintainer/<pkg>-*?)

This is doable, but I'm not sure if it is worth creating branches for 
stuff. If you need to maintain two versions concurrently (like you might 
want to for stuff like apache) it might be as easy to create two 
directories with their own trunk (like apache/trunk and apache2/trunk).

> We still need a solution for Solaris 8 x86 packages containing
> 64 bit code.

I think having 32 and 64 bit packages is the best, perhaps with some 
clever logic in pkg-get to fetch the foo_64 package for the foo package. 
The 64 bit package would have to depend on the 32 bit package. This is 
definitely a useful subject to talk about in Zürich over a beer.

--
Trygve