Re: "ago" times on buildfarm status page

From: "Tom Turelinckx" <pgbf(at)twiska(dot)com>
To: "Andrew Dunstan" <andrew(dot)dunstan(at)2ndquadrant(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Magnus Hagander" <magnus(at)hagander(dot)net>, "Peter Eisentraut" <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "ago" times on buildfarm status page
Date: 2019-08-27 08:33:39
Message-ID: 92a3802e-96b6-44f4-84dd-a5ef7cac5698@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 26, 2019, at 9:08 PM, Andrew Dunstan wrote:
> I think this is the problem:
>
> 'scmrepo' => '/home/pgbf/pgmirror.git',
>
> Probably this isn't updated often enough. It probably has little to do with the clock settings.
>
> This is the kind of old-fashioned way of doing things. These days "git_keep_mirror => 1" along with the community repo as the base would avoid these problems.

We've discussed this before (see below).

The configuration is intentionally like that. I specifically configured skate and snapper to build the exact same source, where skate builds with default buildfarm settings, while snapper builds with the settings actually used by Debian source packages.

These animals were set up to avoid cases we had in the past where Debian source packages failed to build on sparc, even though build animals running on Debian sparc were building fine:

https://www.postgresql.org/message-id/000001d2f0c2%24e2d335a0%24a879a0e0%24%40turelinckx.be

With snapper building the exact same source as skate (as it is now), we have some point of reference if snapper fails but skate succeeds. I could configure snapper to perform an update of the repo before building, but then we give up this comparability in exchange for a bit more clarity regarding timestamps.

Best regards,
Tom Turelinckx

On Thu, Nov 9, 2017, at 8:54 PM, Andrew Dunstan wrote:
>
> The first line of the log file is always something like this (see end of https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nightjar&dt=2017-11-09%2018%3A59%3A01 )
>
> Last file mtime in snapshot: Thu Nov 9 17:56:07 2017 GMT
> This should be the time of the last commit in the snapshot.
>
> On Mon, Nov 6, 2017 at 9:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Tom Turelinckx <pgbf(at)twiska(dot)com> writes:
>>
>> > On Fri, Nov 3, 2017, at 09:42 PM, Tom Lane wrote:
>> >> Either that, or it's fallen through a wormhole ;-), but the results
>> >> it's posting seem to be mis-timestamped by several hours, which is
>> >> confusing. Please set its clock correctly. Maybe spin up ntpd?
>>
>> > The clock is correct, but the configuration may be unusual.
>>
>> > In fact, snapper runs on the same machine as skate, and it's using ntp.
>> > At 7 AM (Western Europe), a local git repo is updated. In the morning,
>> > skate builds from that local repo with the default buildfarm
>> > configuration that most animals use. In the afternoon, snapper builds
>> > from that local repo with the exact same configuration, per branch, that
>> > the Debian source packages from the pgdg repo use on the same platform.
>> > The local repo is updated only once per day to ensure that snapper and
>> > skate build the same source with different settings, and they share the
>> > git mirror and build root, as suggested in the build farm howto.
>>
>> Hm. So the issue really is that the build timestamp that the buildfarm
>> client is reporting tells when it pulled from the local repo, not when
>> that repo was last updated from the community server. Not sure if there's
>> any simple way to improve that ... Andrew, any thoughts?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rafia Sabih 2019-08-27 08:36:06 Re: Creating partitions automatically at least on HASH?
Previous Message Asif Rehman 2019-08-27 08:19:19 Re: pgbench - allow to create partitioned tables