Thread: Re: Release 17 of the PostgreSQL Buildfarm Client

Andrew Dunstan <andrew@dunslane.net> writes:
> I have pushed Release 17 of the PostgreSQL Buildfarm client.

I ran a test of this using

run_branches.pl --run-all --nosend --force

and noticed that it created "animal.force-one-run" files in each
of the per-branch directories, and never removed them.  This
means (I assume) that the next run will also behave like --force
... and maybe all later ones too, until I manually remove those
files?

I'm not sure if this behavior is new in v17, or I just never
tried it before.  I usually create force-one-run files manually.

            regards, tom lane

I wrote:
> I ran a test of this using
> run_branches.pl --run-all --nosend --force
> and noticed that it created "animal.force-one-run" files in each
> of the per-branch directories, and never removed them.

Further testing shows that a pre-existing force-one-run file does
get removed, so use-cases involving manual creation of the file
are still OK.  Maybe this "force twice" from --force has been
there all along, and nobody noticed?  Even if it's a new bug,
it's not a show-stopper.

            regards, tom lane

I wrote:

I ran a test of this using
run_branches.pl --run-all --nosend --force
and noticed that it created "animal.force-one-run" files in each
of the per-branch directories, and never removed them.

Further testing shows that a pre-existing force-one-run file does
get removed, so use-cases involving manual creation of the file
are still OK.  Maybe this "force twice" from --force has been
there all along, and nobody noticed?  Even if it's a new bug,
it's not a show-stopper.
		

This isn't a product of the --force flag. It's done so that --nosend and --nostatus don't defeat the up-to-date checks in run_branches.pl by writing a githead.log with a gitref we haven't reported on. We could possibly do that another way, e.g. by removing or renaming the githead.log file in such cases, since the checks in run_branches.pl rely on that name. (thinks) In fact that's probably better, because instead of forcing a run it would just make the code do a slow up-to-date check (by doing a git pull) next time around. Will fix.

If you had used --test instead of --nosend this wouldn't have happened.

In any case, the next regular run (i.e. one without --nosend or --nostatus) will remove the files.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 2023-08-04 Fr 21:25, Tom Lane wrote:

I wrote:

I ran a test of this using
run_branches.pl --run-all --nosend --force
and noticed that it created "animal.force-one-run" files in each
of the per-branch directories, and never removed them.

Further testing shows that a pre-existing force-one-run file does
get removed, so use-cases involving manual creation of the file
are still OK.  Maybe this "force twice" from --force has been
there all along, and nobody noticed?  Even if it's a new bug,
it's not a show-stopper.
		

This isn't a product of the --force flag. It's done so that --nosend and --nostatus don't defeat the up-to-date checks in run_branches.pl by writing a githead.log with a gitref we haven't reported on. We could possibly do that another way, e.g. by removing or renaming the githead.log file in such cases, since the checks in run_branches.pl rely on that name. (thinks) In fact that's probably better, because instead of forcing a run it would just make the code do a slow up-to-date check (by doing a git pull) next time around. Will fix.

If you had used --test instead of --nosend this wouldn't have happened.

In any case, the next regular run (i.e. one without --nosend or --nostatus) will remove the files.

See <https://github.com/PGBuildFarm/client-code/commit/ec4cf43613a74cb88f228efcde09931cf9fd57e7>

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com