[Pgbuildfarm-members] triggering builds - new skin

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

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

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