triggering builds - new skin

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

triggering builds - new skin

Andrew Dunstan

I am thinking of making the trigger for doing a new build a little less
sensitive by excluding docs and translation files from consideration.
Changes in them would still be added when a new build is done.

Currently the test for not doing a build says:

    if ($last_status && ! @changed_files)

The would become something like:

    my @trigger_files = grep { ! m'/(doc|po)/' } @changed_files;
    if ($last_status && ! @trigger_files)

The advantage would be that we would only trigger builds when more
significant things (i.e. code!) change, so the build history would
become more useful, with less dross.

Thoughts?

Lastly, many many thanks to Michael Glaesemann for the lovely new skin
for the buildfarm web site. Also, some of you might not be aware that
the web site is provided by CommandPrompt - many thanks also go to them.



cheers

andrew

Reply | Threaded
Open this post in threaded view
|

Re: triggering builds - new skin

Kris Jurka


On Thu, 30 Dec 2004, Andrew Dunstan wrote:

> The advantage would be that we would only trigger builds when more
> significant things (i.e. code!) change, so the build history would
> become more useful, with less dross.
>

You could also consider modifying the display to not simply show the last
thirty build runs, but the last thirty status changes.  This
would compress your consecutive successes something like this:

03:12:45 ago                  InstallCheck
07:12:45 ago -> 20 days ago   53 OK
21 days ago                   Initdb
22 dyas ago  -> 45 days ago   60 OK

The problem with this approach is that it doesn't detect/show config
changes over the course of the many successful runs.  Not that it's easy
to do that with the current system.  Naturally you wouldn't want to
compress failures unless you were sure they really were the same failure,
but I imagine these logs are stored in one bulk text field making it
difficult to do such comparisons.

Kris Jurka

Reply | Threaded
Open this post in threaded view
|

Re: triggering builds - new skin

Andrew Dunstan


Kris Jurka wrote:

>On Thu, 30 Dec 2004, Andrew Dunstan wrote:
>
>  
>
>>The advantage would be that we would only trigger builds when more
>>significant things (i.e. code!) change, so the build history would
>>become more useful, with less dross.
>>
>>    
>>
>
>You could also consider modifying the display to not simply show the last
>thirty build runs, but the last thirty status changes.  
>

I'm intending to increase the 30 to around 90. But still, building if
nothing that can sigificantly affect the build result has changed seems
quite unnecessary to me.

Perhaps I should only ignore the po directories if --enable-nls is not set.

>This
>would compress your consecutive successes something like this:
>
>03:12:45 ago                  InstallCheck
>07:12:45 ago -> 20 days ago   53 OK
>21 days ago                   Initdb
>22 dyas ago  -> 45 days ago   60 OK
>
>The problem with this approach is that it doesn't detect/show config
>changes over the course of the many successful runs.  Not that it's easy
>to do that with the current system.  Naturally you wouldn't want to
>compress failures unless you were sure they really were the same failure,
>but I imagine these logs are stored in one bulk text field making it
>difficult to do such comparisons.
>
>
>  
>

Yes, it would be difficult. But if we only compressed successes that
might be reasonable.

Regarding config changes - I hope there aren't too many. Especially in
OS,  compiler  etc. That really would be a time for a new member -
otherwise the member name is close to meaningless as a history tracker.

cheers

andrew