Checking CI servers
Mauricio Scheffer
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
- 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?
--
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
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:
>
> - I'd personally prefer a build against trunk, then resorting to the
> 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.
> the horn build until the build server completes, or revert to the previous
> good revision etc.
> > .
Paul Cowan
Paul Cowan
Cutting-Edge Solutions (Scotland)
http://thesoftwaresimpleton.blogspot.com/
To unsubscribe from this group, send email to horn-developme...@googlegroups.com.
Paul Cowan
Should it not be the job of the OSS project in question to provide stable builds??
G. Richard Bellamy
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
John Simons
> versions are locked down as much as possible.
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
A lot of projects will still be referencing and have castle binaries from the old trunk.
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.
To unsubscribe from this group, send email to horn-developme...@googlegroups.com.
Eric Hauser
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
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 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.
To unsubscribe from this group, send email to horn-developme...@googlegroups.com.