Content-Type: multipart/alternative;
 boundary="------------2cM47OvyKpkrimvXbppmUpBc"
Message-ID: <793aa36e-e0a9-ca2e-c350-bac7054105cf@dunslane.net>
Date: Sat, 5 Aug 2023 06:40:27 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "buildfarm-members@lists.postgresql.org"
 <buildfarm-members@lists.postgresql.org>
References: <6e00da65-f0dc-3fa7-8b06-49385e08d05c@dunslane.net>
 <3951994.1691190865@sss.pgh.pa.us> <3973102.1691198716@sss.pgh.pa.us>
From: Andrew Dunstan <andrew@dunslane.net>
Subject: Re: Release 17 of the PostgreSQL Buildfarm Client
In-Reply-To: <3973102.1691198716@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/793aa36e-e0a9-ca2e-c350-bac7054105cf%40dunslane.net>
Precedence: bulk

This is a multi-part message in MIME format.
--------------2cM47OvyKpkrimvXbppmUpBc
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


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.


cheers


andrew

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

--------------2cM47OvyKpkrimvXbppmUpBc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2023-08-04 Fr 21:25, Tom Lane wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:3973102.1691198716@sss.pgh.pa.us">
      <pre class="moz-quote-pre" wrap="">I wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">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.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
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.

		</pre>
    </blockquote>
    <p><br>
    </p>
    <p>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.<br>
    </p>
    <p>If you had used --test instead of --nosend this wouldn't have
      happened.</p>
    <p>In any case, the next regular run (i.e. one without --nosend or
      --nostatus) will remove the files.<br>
    </p>
    <p><br>
    </p>
    <p>cheers</p>
    <p><br>
    </p>
    <p>andrew<br>
    </p>
    <pre class="moz-signature" signature-switch-id="d0437855-2267-4610-80b3-83167ec45b0b" cols="72">--
Andrew Dunstan
EDB: <a class="moz-txt-link-freetext" href="https://www.enterprisedb.com">https://www.enterprisedb.com</a>
</pre>
  </body>
</html>

--------------2cM47OvyKpkrimvXbppmUpBc--