WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
I'm not certain how to compare it to Adam's old system since I wasn't
intimately familiar with it.
Jenkins is a continuous integration system. It checks out and builds
the source periodically and reports any errors back to either the
users who broke the build or to a given email address. I selected the
gnustep-dev list because it seemed the most logical choice. I can
change this so that it only sends it to me and a few others.
Nevertheless I would like it to notify more than just me in case of a
failure. It is, in fact, supposed to be a little annoying so that
people are inspired to fix it when it breaks. ;) The way I have it
configured right now is that it will ONLY notify the list if there is
a failure; it should be silent otherwise.
Jenkins is written in Java and can run on pretty much any platform we
I noticed that you made all of the tests in gui as dashed hopes.
That's fine. What I thought would be best, and I was going to check
with you and Richard on this, is to add the tests for base first and
then we could work on fleshing out the tests for gui a bit more and,
when we're confident, we can add them to the jenkins build as well.
I'm not sure how much good our testing framework does for us on GUI,
though since, while it's easy to test Foundation/base with it, it's
not very easy to test AppKit/gui. There's too much which depends on
the eye and determining if it "looks" right in GUI.
> Could you please explain how this setup compares to the old nightly build
> system that Adam used to provide? The benefit there was that it allowed
> multiple machines to register as build hosts. Normally the build works fine
> on the machine of the submitter, we need completely different setups to
> detect the problems with submits.
> It would be just great if there were an easy way to move over the old
> distributed build farm to the new system.
> Running the tests on your machine is surely fine, but sending out mails on
> failed tests may be a bit annoying. In gui we have a few tests that are
> known failures. I am going to mark all of the as "dashed hopes" for now. The
> problem here is that we want to encourage people to write more test code, if
> a failed test ends up with a mail to everybody this may not send the right
> On 28.03.2012 14:57, Gregory Casamento wrote:
>> It shouldnt. It should be on a relatively high traffic list, since its
>> important that the messages be recieved.
>> No failed builds yet. ;). Im going to add the unit tests today.
>> On Wednesday, March 28, 2012, Ivan Vučica<ivucica@...> wrote:
>>> Let's hope it doesn't end up spamming everyone tracking -dev ;)
>>> If it does, it may make sense to send those mails to a separate mailing
>>> On Wed, Mar 28, 2012 at 07:43, Gregory
>>>> Hey guys,
>>>> I have set up a local Jenkins instance which builds GNUstep whenever
>>>> there is a change.
>>>> I have configured it to email the gnustep-dev@... list whenever
>>>> the build is broken. Currently it is only configured to run the build
>>>> itself, but I plan on adding the unit tests as well. This way we can
>>>> see immediately when the build is broken or when one of the tests is
> Gnustep-dev mailing list
> Gnustep-dev@... > https://lists.gnu.org/mailman/listinfo/gnustep-dev