Обсуждение: Re: Release 13 of the PostgreSQL BuildFarm client
Andrew Dunstan <andrew@dunslane.net> writes:
> I have pushed Release 13 of the PostgreSQL BuildFarm client.
FYI, this seems to have broken compatibility with ancient versions
of git. prairiedog and gaur/pademelon are both using
git version 1.7.9.6, and they both choked on the --prune-tags
option. I tried removing that, as it seemed possibly unnecessary,
but it didn't improve matters.
I suppose I'm overdue to update git on these machines, but anyone
else running dinosaur versions may want to be cautious.
regards, tom lane
On 8/2/21 7:11 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> I have pushed Release 13 of the PostgreSQL BuildFarm client. > FYI, this seems to have broken compatibility with ancient versions > of git. prairiedog and gaur/pademelon are both using > git version 1.7.9.6, and they both choked on the --prune-tags > option. I tried removing that, as it seemed possibly unnecessary, > but it didn't improve matters. Ouch. --prune-tags possibly is unnecessary. What happens when you remove it from the code? I will test tomorrow or Wednesday on a Centos5 docker - there is an image on dockerhub with git 1.6. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes: > --prune-tags possibly is unnecessary. What happens when you remove it > from the code? This: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gaur&dt=2021-08-03%2002%3A07%3A56 which I can't make much sense of. regards, tom lane
> On Aug 2, 2021, at 10:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Andrew Dunstan <andrew@dunslane.net> writes: >> --prune-tags possibly is unnecessary. What happens when you remove it >> from the code? > > This: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gaur&dt=2021-08-03%2002%3A07%3A56 > > which I can't make much sense of. I guess it’s failing on the ls-remote or symbolic-ref command. Cheers Andrew
On 8/2/21 7:11 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> I have pushed Release 13 of the PostgreSQL BuildFarm client. > FYI, this seems to have broken compatibility with ancient versions > of git. prairiedog and gaur/pademelon are both using > git version 1.7.9.6, and they both choked on the --prune-tags > option. I tried removing that, as it seemed possibly unnecessary, > but it didn't improve matters. > > I suppose I'm overdue to update git on these machines, but anyone > else running dinosaur versions may want to be cautious. Not so much dinosaurs either. I just tried on Centos 7 which isn't that old, and got a failure. Not just from the prune-tags but from 'git ls-remote' not supporting symref. I will come up with a solution in a couple of days, but for now please don't deploy unless you have a fairly modern git. If you do deploy, be prepared to roll back. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
On 8/3/21 8:47 AM, Andrew Dunstan wrote: > On 8/2/21 7:11 PM, Tom Lane wrote: >> Andrew Dunstan <andrew@dunslane.net> writes: >>> I have pushed Release 13 of the PostgreSQL BuildFarm client. >> FYI, this seems to have broken compatibility with ancient versions >> of git. prairiedog and gaur/pademelon are both using >> git version 1.7.9.6, and they both choked on the --prune-tags >> option. I tried removing that, as it seemed possibly unnecessary, >> but it didn't improve matters. >> >> I suppose I'm overdue to update git on these machines, but anyone >> else running dinosaur versions may want to be cautious. > > Not so much dinosaurs either. I just tried on Centos 7 which isn't that > old, and got a failure. Not just from the prune-tags but from 'git > ls-remote' not supporting symref. I will come up with a solution in a > couple of days, but for now please don't deploy unless you have a fairly > modern git. If you do deploy, be prepared to roll back. > > OK, I have come up with this fix. Essentially the code detects if the git version can run `git ls-remote --symref` and refuses to run branch name checking code if it fails. It also outputs a warning message unless the config setting skip_git_default_check has been explicitly set. In either case the owner will have to update their git installation or face a flag day event when the default branch name changes. I have tested this on Centos 7 which has a git that's plenty old enough to exhibit the problems Tom encountered. I'm planning on issuing a 12.1 release fairly soon with this patch, but as I developed it fairly quickly and through the fog of some painkillers I'd appreciate more eyes on it first :-) cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Вложения
Andrew Dunstan <andrew@dunslane.net> writes:
> I'm planning on issuing a 12.1 release fairly soon with this patch, but
> as I developed it fairly quickly and through the fog of some painkillers
> I'd appreciate more eyes on it first :-)
I tested this on gaur, and it seems to work --- at least, it gets
through the git checkout step now. (It'll be a few hours before
the run finishes.)
One nit is that personally I could do without this:
+ my $gversion = `git --version`;
+ chomp $gversion;
+ print "$gversion too old to for automatic default branch update\n";
Aside from the message typo, that'll produce useless every-run chatter in
affected owners' cron logs. I'd probably soon set skip_git_default_check
to silence it, at which point it might as well not be there.
Thanks for fixing it, though. I wasted a couple of hours last night
trying to build current git on prairiedog and gaur, with no luck so far.
I think just blowing away their git repos when the master-branch rename
happens will be a much more appropriate amount of effort.
regards, tom lane
On 8/3/21 4:00 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> I'm planning on issuing a 12.1 release fairly soon with this patch, but >> as I developed it fairly quickly and through the fog of some painkillers >> I'd appreciate more eyes on it first :-) > I tested this on gaur, and it seems to work --- at least, it gets > through the git checkout step now. (It'll be a few hours before > the run finishes.) > > One nit is that personally I could do without this: > > + my $gversion = `git --version`; > + chomp $gversion; > + print "$gversion too old to for automatic default branch update\n"; > > Aside from the message typo, that'll produce useless every-run chatter in > affected owners' cron logs. I'd probably soon set skip_git_default_check > to silence it, at which point it might as well not be there. I'll fix the typo and make it only print the warning in verbose mode, I hope that will suit. On those machines where you can't update git you should just set skip_git_default_check. > > Thanks for fixing it, though. I wasted a couple of hours last night > trying to build current git on prairiedog and gaur, with no luck so far. > I think just blowing away their git repos when the master-branch rename > happens will be a much more appropriate amount of effort. > > Indeed. I've been down that path before, with similar success. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
> On 8/3/21 4:00 PM, Tom Lane wrote:
>> Aside from the message typo, that'll produce useless every-run chatter in
>> affected owners' cron logs. I'd probably soon set skip_git_default_check
>> to silence it, at which point it might as well not be there.
> I'll fix the typo and make it only print the warning in verbose mode, I
> hope that will suit.
Sure, works for me.
regards, tom lane