Re: "ago" times on buildfarm status page

Поиск
Список
Период
Сортировка
От Tom Turelinckx
Тема Re: "ago" times on buildfarm status page
Дата
Msg-id 92a3802e-96b6-44f4-84dd-a5ef7cac5698@www.fastmail.com
обсуждение исходный текст
Ответ на Re: "ago" times on buildfarm status page  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: "ago" times on buildfarm status page  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Re: "ago" times on buildfarm status page  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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
repoas 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
Debiansource packages.
 

These animals were set up to avoid cases we had in the past where Debian source packages failed to build on sparc, even
thoughbuild 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
butskate succeeds. I could configure snapper to perform an update of the repo before building, but then we give up this
comparabilityin 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@sss.pgh.pa.us> wrote:
>>
>> Tom Turelinckx <pgbf@twiska.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?



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Asif Rehman
Дата:
Сообщение: Re: pgbench - allow to create partitioned tables
Следующее
От: Rafia Sabih
Дата:
Сообщение: Re: Creating partitions automatically at least on HASH?