Checking CI servers

1 view
Skip to first unread message

Mauricio Scheffer

unread,
Dec 15, 2009, 11:42:47 PM12/15/09
to HORN Development
The current descriptors build the projects without running their
tests. I know this was discussed months ago and I agree with the
decision.

However many OSS projects have public CI servers, IMO it would be
useful to optionally check their build status before fetching and
building (especially for trunk descriptors). Something like this:

assert_build_status_from teamcity("http://teamcity.codebetter.com/
feed.html?
buildTypeId=bt7&itemsType=builds&guest=1&sinceDate=60&itemsCount=1")

That URL has the build status for NHibernate trunk. A little parsing
and you can get an ok/failed.
Same thing could be done for CruiseControl, Hudson, etc.

What do you think?

--
Mauricio

Alex Henderson

unread,
Dec 16, 2009, 12:30:04 AM12/16/09
to horn-dev...@googlegroups.com
I'm curious as to what's the guarantee you're offering here - that any package you download from hornget has passed all it's tests, if it has any, and the project has a publicly accessible build server configured in the descriptor?

Seems to me that if that's the guarantee you're trying to provide, then you'll have a hard time supporting that guarantee 100% - I'm thinking:
  • What's the expected outcome if the build server can't be contacted?
    • I'd personally prefer a build against trunk, then resorting to the last "good" build.  But that does violate the guarantee.
  • If the build is failing on the builder server, is the outcome then to use the revision horn currently has - what happens if this is the first build being performed for the descriptor? Especially for a local horn instance (rather then using say hornget.net).  I guess a command line override might be OK in these cases - some sort of IgnoreTestStatus switch.
  • Possible temporal issues - if a build is in progress on the build server while horn is attempting to build the package... should this block the horn build until the build server completes, or revert to the previous good revision etc.
  • What advantage do I get from knowing I'm not using code from a failing build?
I would be weary of either stopping people from having access to the bleeding edge when tests are failing, or providing some false sense of security where the user thinks they're working against a set of libraries built against a revision where all the test's passed, when that may not always be true. My 2ø worth at least... 

That said, what about idea of incorporating additional metadata pulled from remote sources (like the build server status) at build time - which could then be presented on the package's hornget.net download page, much like the current descriptor forum etc. links work?

Cheers,

 - Alex



--

You received this message because you are subscribed to the Google Groups "HORN Development" group.
To post to this group, send email to horn-dev...@googlegroups.com.
To unsubscribe from this group, send email to horn-developme...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/horn-development?hl=en.



Mauricio Scheffer

unread,
Dec 16, 2009, 8:24:37 AM12/16/09
to HORN Development
Yep, I know it's pretty much impossible to assure that a build is 100%
ok. A library built against its binary dependencies is not the same
library when built against trunk dependencies.
I was thinking about a big warning in case the current build status is
"failed" or N/A.

What I'm really looking for is to get reliable builds. The current
descriptors depend too much on trunks. Most people just want stable,
production-quality builds. Maybe we should just write a set of
"stable" descriptors where dependency versions are locked down as much
as possible.

Cheers,
Mauricio

On Dec 16, 2:30 am, Alex Henderson <bitterco...@gmail.com> wrote:
> I'm curious as to what's the guarantee you're offering here - that any
> package you download from hornget has passed all it's tests, if it has any,
> and the project has a publicly accessible build server configured in the
> descriptor?
>
> Seems to me that if that's the guarantee you're trying to provide, then
> you'll have a hard time supporting that guarantee 100% - I'm thinking:
>
>    - What's the expected outcome if the build server can't be contacted?
>       - I'd personally prefer a build against trunk, then resorting to the
>       last "good" build.  But that does violate the guarantee.
>    - If the build is failing on the builder server, is the outcome then to
>    use the revision horn currently has - what happens if this is the first
>    build being performed for the descriptor? Especially for a local horn
>    instance (rather then using say hornget.net).  I guess a command line
>    override might be OK in these cases - some sort of IgnoreTestStatus switch.
>    - Possible temporal issues - if a build is in progress on the build
>    server while horn is attempting to build the package... should this block
>    the horn build until the build server completes, or revert to the previous
>    good revision etc.
>    - What advantage do I get from knowing I'm not using code from a failing
> > horn-developme...@googlegroups.com<horn-development%2Bunsubscrib e...@googlegroups.com>
> > .

Paul Cowan

unread,
Dec 16, 2009, 9:25:05 AM12/16/09
to horn-dev...@googlegroups.com
>> Maybe we should just write a set of "stable" descriptors where dependency versions are locked down as much as possible.

I think this is possibly the easiest idea to get it working.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2009/12/16 Mauricio Scheffer <mauricio...@gmail.com>
To unsubscribe from this group, send email to horn-developme...@googlegroups.com.

Paul Cowan

unread,
Dec 16, 2009, 10:14:59 AM12/16/09
to horn-dev...@googlegroups.com
I guess this was one of the reasons why horn was started was in order to get the latest versions of open source code and resolve the dependencies that make this a viable option.

Should it not be the job of the OSS project in question to provide stable builds??


Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2009/12/16 Paul Cowan <dag...@scotalt.net>

G. Richard Bellamy

unread,
Dec 16, 2009, 10:04:12 AM12/16/09
to horn-dev...@googlegroups.com, HORN Development
A set of descriptors pointing to the branch/tags (depending on repo
type svn/git) perhaps?

Sent from my mobile device. Please excuse any errors or omissions.

On Dec 16, 2009, at 5:24 AM, Mauricio Scheffer <mauricio...@gmail.com
> devel...@googlegroups.com.
> To unsubscribe from this group, send email to horn-developme...@googlegroups.com

John Simons

unread,
Dec 20, 2009, 4:56:11 AM12/20/09
to HORN Development
> Maybe we should just write a set of "stable" descriptors where dependency
> versions are locked down as much as possible.
I agree, if horn wants to guarantee a working + stable build then that
has to be the way.

>Should it not be the job of the OSS project in question to provide stable
>builds??

Yes, if the user want a stable release then get it from the OSS
website, eg Castle has their releases published at
https://sourceforge.net/projects/castleproject/files/


Cheers
John

On Dec 17, 2:04 am, "G. Richard Bellamy" <rbell...@pteradigm.com>
wrote:


> A set of descriptors pointing to the branch/tags (depending on repo  
> type svn/git) perhaps?
>
> Sent from my mobile device. Please excuse any errors or omissions.
>

> On Dec 16, 2009, at 5:24 AM, Mauricio Scheffer <mauricioschef...@gmail.com

Paul Cowan

unread,
Dec 20, 2009, 5:44:55 AM12/20/09
to horn-dev...@googlegroups.com
>> Yes, if the user want a stable release then get it from the OSS website, eg Castle has their releases published at

In an ideal world everybody would be referencing these castle dependencies but this is not always the case.

A lot of projects will still be referencing and have castle binaries from the old trunk.

I have had a nightmare with horn and all the different boo libraries that are doing the rounds in various bin folders.

It would be really good if all .NET oss could pull libraries like boo from a central location and perhaps this could help ease the dependency nightmare we are all experiencing.


Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2009/12/20 John Simons <johnsi...@yahoo.com.au>
To unsubscribe from this group, send email to horn-developme...@googlegroups.com.

Eric Hauser

unread,
Dec 21, 2009, 9:40:44 PM12/21/09
to HORN Development
Paul,

I have been taking a look at horn a bit, and I had a few ideas. Your
statement about it being good if .NET oss pulling libraries from a
central source is dead on. I think one of the ones that horn could
help facilitate that would be by providing a Maven repository from the
builds it creates.

First, I want to be clear that I am not suggesting projects would have
to use Maven to build their projects -- I don't think this is
reasonable for .NET projects. What I am suggesting is that horn could
build a Maven compatible repository of the binaries it builds. This
is a fairly simple process:

1. You would have to generate a simple XML document that contains the
elements listed on this page: http://maven.apache.org/guides/mini/guide-central-repository-upload.html.
A lot of this data is already in the .boo files in the horn
repository. It looks like the main thing you are missing right now is
version and license, but that simple to collect.
2. Generate a MD5 hash of the DLL and the pom.xml
3. Deploy the built artifacts to a repository, usually available via
HTTP, the following naming convention: /<groupId>/<artifactId>/
<version>/<artifactId>-<version>.<packaging> . Since you are building
from trunk, you would always append the -SNAPSHOT convention after the
version.

Despite many people having a love/hate relationship with the Maven
build tool, the repository format has become the de facto standard for
sharing dependencies. Just to give an idea of some things that have
all standardized on the repository 1) Build tools - Maven, Apache Ivy,
Grails 2) Google Code (for Google releases), TeamCity (can act as an
Ivy repository) 3) Nexus and Artifactory (repository managers). There
is even early gem support for downloading dependencies in the Maven
repository.

What would this gain for .NET oss? Even though there are not any
native .NET tools that interface with Maven repository, I've built and
run Ivy with IKVM before and it works great. Since there is already a
community around the repository structure, it just seems to make
sense. Eventually, native .NET tools will source (task libraries for
NAnt, etc).

I think what you are doing with horn is great and has a definite need,
but I think this can take the concept one step further. Like you
said, having a standard way for .NET oss to share libraries would
really be useful -- and help to drive adoption. If you there is some
interest, I would be willing to lend a hand.

On 20 Dec, 05:44, Paul Cowan <dag...@scotalt.net> wrote:
> >> Yes, if the user want a stable release then get it from the OSS website,
>
> eg Castle has their releases published at
>
> In an ideal world everybody would be referencing these castle dependencies
> but this is not always the case.
>
> A lot of projects will still be referencing and have castle binaries from
> the old trunk.
>
> I have had a nightmare with horn and all the different boo libraries that
> are doing the rounds in various bin folders.
>
> It would be really good if all .NET oss could pull libraries like boo from a
> central location and perhaps this could help ease the dependency nightmare
> we are all experiencing.
>
> Cheers
>
> Paul Cowan
>
> Cutting-Edge Solutions (Scotland)
>
> http://thesoftwaresimpleton.blogspot.com/
>

> 2009/12/20 John Simons <johnsimons...@yahoo.com.au>

> > horn-developme...@googlegroups.com<horn-development%2Bunsubscrib e...@googlegroups.com>


> > > > .
> > > > For more options, visit this group athttp://
> > groups.google.com/group/horn-development?hl=en

> > > > .
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "HORN Development" group.
> > To post to this group, send email to horn-dev...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > horn-developme...@googlegroups.com<horn-development%2Bunsubscrib e...@googlegroups.com>

Paul Cowan

unread,
Dec 22, 2009, 4:21:23 AM12/22/09
to horn-dev...@googlegroups.com
Thanks for the input Eric, it is always good to see people taking an interest.

To me, .NET OSS still seems very like the wild west, with absolutely no standards or  no collaboration in any shape or form between projects.  Why else would we have so many differing libraries?  I was stunned at the amount of different boo libraries each project has (horn included).

Somebody else on this list had mentioned bringing in Maven standards and there even is a NMaven or NPaladay or something that it might be interesting to see if we could bring any collaboration with these guys. 

I love the sound of the consistency and ease that a maven initiative would bring to .NET.

I really like the idea of bringing this consistency but I now know after my fumblings with horn how hard it is to generate interest and buy in from the other guys.


>>  I would be willing to lend a hand.

I would love people to drive horn forward.  I have given it my shot and got so far but I would love somebody else to take over and give it a shot.


Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2009/12/22 Eric Hauser <ewha...@gmail.com>
To unsubscribe from this group, send email to horn-developme...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages