On 13 October 2010 21:42, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On 10/13/2010 2:52 PM, BRM wrote:
>>
>>> From: Les Mikesell<lesmikesell_at_gmail.com>
>>> We currently commit component binaries back into tags which are then
>>> used by
>>> other things with external references, and final binaries are managed
>>> separately by project, but that seems wrong on several levels.
>>
>> For the projects we do nightly builds on we use an FTP site that the build
>> scripts upload the builds to. This is easy enough to script even on
>> Windows -
>> whether using DOS Batch or Windows Scripting Host.
>> I'm sure Hudson and other build systems can handle that just fine.
>>
>>> I'd like to find a generic scheme (and one that can be plugged into
>>> hudson if
>>> possible) to store build results with a versioning scheme that
>>>
>>> doesn't force you to keep them forever because most are obsolete after a
>>> few
>>> new builds but that has a close-coupling to the svn version
>>> or at least the tag name of the matching source. But this seems like it
>>> should be a common scenario and not something everyone re-invents
>>> differently.
>>
>> Well, right now I have a lot of projects that don't have a nightly build -
>> mostly due to how Qt and Visual Studios interact - or rather, the problems
>> in
>> doing so.
>> However, you can do a couple things to track this very well and
>> automatically,
>> partially supported via Subversion's Keyword Substitution.
>> I use $HeadUrl$ in a number of projects to get the URL, which I then parse
>> to
>> get a information about the build; for example, if it's a tag then I grab
>> the
>> release information, or a branch then I build a special branch info to
>> output.
>>
>> For things like the global revision number you'll need to use 'svnversion'
>> to
>> capture the output somehow.
>>
>> The following would probably work for you:
>>
>> 1. Capture the URL somewhere as part of checking it out using $HeadURL$
>> 2. As part of the build script run and capture the output of "svnversion",
>> you
>> might want to do so with "svn info" too - though this only works if you
>> are NOT
>> doing an export.
>>
>> You can then store these with a copy of the source and resulting binaries
>> to
>> have full traceability.
>> Alternatively, if you are using "svn co" in the build, just tarball or zip
>> up
>> the project's sandbox at the end of the build script and save it as a
>> whole -
>> this will keep ALL the information, URLs, versions, etc; for you - and is
>> very
>> build system friendly too.
>
> This covers the 'backtrack from binary' scenario as long as you keep those
> extra pieces in the zip with them. But I'm looking more for a filesystem
> and/or http URL name/path mapping to store the binaries so you can easily
> find the currently relevant versions in the first place.
Use Nexus (A maven repository manager)
The backing store is on the file system.
It has a searchable interface that can be used over http to, e.g. get
the latest version (IIRC even the latest version within a range, e.g
[1.0,2.0) will ensure I never get any of the 2.0 artifacts)
It's very lightweight and almost trivial to install.
Oh and the open source edition is free! I've used the pro edition and
it's great but the OSS is fine for most use cases... the only thing I
miss from the pro is the staging support
-Stephen
P.S. I am just a happy Nexus user, I have no affiliation with Sonatype
at present.
> Among other things
> it should provide a straightforward way to replace our current svn externals
> to pull specific libraries into place for dependent builds, and also map to
> our branch/tag name structure for qa and production releases. Maven may be
> the right answer, but I was thinking in terms of something that could be
> viewed as a filesystem - maybe like alfresco where additional rules can be
> imposed.
>
> --
> Les Mikesell
> lesmikesell_at_gmail.com
>
>
Received on 2010-10-14 09:46:45 CEST