From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | buildfarm-members(at)postgresql(dot)org |
Subject: | Re: many animals are running old clients |
Date: | 2018-08-21 03:24:40 |
Message-ID: | 20180821032440.GA217087@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | buildfarm-members |
On Sun, Aug 19, 2018 at 03:04:58PM -0400, Andrew Dunstan wrote:
> On 08/18/2018 12:22 PM, Noah Misch wrote (offlist):
> >On Sat, Aug 18, 2018 at 08:17:17AM -0400, Andrew Dunstan wrote:
> >>Is there anything I can do to make upgrade easier?
> >The show_log.pl web page could highlight a particular run's config change,
> >including version number changes, when there is such a change compared to the
> >previous run. If it's clear enough that folks are unlikely to confuse an
> >upgrade-induced failure with a PG-commit-induced failure, I could stop checking
> >for post-upgrade buildfarm failures.
>
> What I've done is add this to the database in a way that makes it easily
> accessible to the web app, and added that info to the history page.
I think that wastes prime screen real estate. If show_history.pl is going to
spend that space on something, I would choose commit hash. But I liked it
better with nothing there.
The concept I had in mind was a "Config changed since last success" block
adjacent to the "Files changed since last success" block in show_log.pl. It
might look like this:
- 'config_env' => { 'CC' => 'gcc' },
+ 'config_env' => { 'CC' => 'gcc -mips32r2' },
- 'script_version' => 'REL_7',
+ 'script_version' => 'REL_8',
Script version is a minor aspect, worth little by itself. If you diff the
entire config block, though, that amounts to a meaningful feature.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-08-21 10:58:01 | Re: many animals are running old clients |
Previous Message | Sandeep Thakkar | 2018-08-20 10:32:17 | Re: many animals are running old clients |