[M3devel] hudson suggestions

[Olaf Wagner]

I agree copy & paste and GUI administration isn't great. But as long
as I'm doing most of the release engineering from a closed network
without ssh access, it's the easiest way.

So please let's keep it this way until the release. As I said,
I'll write up generic scripts afterwards. I won't be able to
change those then during the day.

(Cc'ed to m3devel as others may have the same ideas)

Olaf

Quoting Jay K <jay.krell at cornell.edu>:

>
> I think many jobs can be ok, setup as a pipeline, as long the   
> tedious gui editing is minimized.
> Tedious text file editing can be not so bad.
> But if they are short and usually succeed and always run in the same  
>  sequence then maybe no point.
> I can't stand when things get copied around many times and it   
> becomes difficult to keep them in sync where they can or should be   
> the same. For another example some of the m3cc tasks have "clean",   
> some do not.
>
>
> I don't know if Hudson allows it easily, but e.g. there should be   
> just one m3cc task, assigned "sticky" to all nodes except NT386 and   
> then either with "sticky parameters" per-node, or the task uses the   
> Hudson environment variables to figure stuff out. Large that's not   
> even needed, due to the uname sniffing, but e.g. if there were   
> separate SOLsun and SOLgnu nodes or tasks, the Hudson task could set  
>  a parameter.
>
>
> Ok the initial cvs checkout can be non-anonymous.
> And right certainly it should be minimal.
> Like just get one file or just the scripts directory.
> Probably should should be scripts/hudson.
>
>
> scripts/hudson/m3cc
> scripts/hudson/release-build
> scripts/hudson/last-ok-build
> scripts/hudson/test-install
> scripts/hudson/makedist
> etc.
>
>
> preferably NOT multiplied out per target.
> Whenever I see "multiplication" happening I cringe.
> Sure, there is some variation but usually stuff is mostly the same   
> and parameters or #ifdef are imho preferred over copying..
> I understand copy/paste/edit is easier. You don't always know what   
> all the parameters are or how to even have any.
>
> Ideally there is:
> scripts/hudson/install
>
> that takes a hostname, port number, node name, maybe CM3_TARGET   
> value, and sets up a node from scratch.
>
> Currently I don't know enough to do all this and it's much easier to  
>  sit back and suggest it than do any of it, while I lazily continue   
> to edit the gui tediously...
>
>
>
>  - Jay
>
>
> ----------------------------------------
>> Date: Sun, 16 Aug 2009 13:47:58 +0200
>> From: wagner at elegosoft.com
>> To: jay.krell at cornell.edu
>> Subject: Re: hudson suggestions
>>
>> Quoting Jay K :
>>
>>> two suggestions:
>>>
>>> 1) all tasks start with:
>>>
>>> echo hostname
>>> hostname
>>> uname -a
>>
>> That should be no problem, but I haven't got the infrastructure set up
>> to do multiple XML edits, anyway, I only have HTTP access most of the
>> times. So it can just be done incrementally for now.
>>
>>> or more similar
>>>
>>> 2) all tasks
>>> just do roughly but almost exactly
>>> cvs something
>>> run something
>>
>> That's basically what most tasks do. But
>>
>> o CVS needs to be controlled by Hudson to be able to track the changes
>> o we haven't set up generic scripts yet (I'm going to do that ASAP)
>> o We don't want all tasks to check out everything, because that takes
>> rather long depending on the network connections (yours are the
>> best)
>>
>>> It can actually be anonymous cvs to get the intial code.
>> Anonymous CVS asks for a password even if there is none.
>> As we need ssh for reporting anyway, there's no reason not to
>> use it.
>>
>>> They would all get the same thing generally.
>>> Hudson probably sets enough environment variables -- task name -- for
>>> cvs+run to then decide what to do, and what architecture on   
>>> multiarch systems
>>> to use, based on strings in the task name.
>>>
>>> We can/should also check more stuff up front.
>>> Like availability of cc and/or gcc, bc, gnu tar, simple C link tests
>>> against -lX11, etc.
>>> But first transform the tasks into cvs+run only.
>>>
>>> I started putting in the hostname/uname -- make sure I put nodes
>>> back where you
>>> expect them, but it is too tedious to go through the gui.
>>
>> That's all I have most of the time ;-)
>>
>> We also need to reduce the number of jobs; I'm thinking of
>> combining the builds and the package tests.
>>
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194