git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: redoste <redoste@redoste.xyz>, Phillip Wood <phillip.wood@dunelm.org.uk>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	Fabian Stelzer <fs@gigacodes.de>,
	Junio C Hamano <gitster@pobox.com>,
	Elijah Newren <newren@gmail.com>, Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH v2] ssh signing: don't detach the filename strbuf from key_file tempfile
Date: Mon, 7 Jul 2025 16:26:42 +0100	[thread overview]
Message-ID: <7130651b-76a6-4eb1-93cf-c9e237d398d7@gmail.com> (raw)
In-Reply-To: <DB5W4LH0MI5K.EJ0IILQ1IWR@redoste.xyz>

On 07/07/2025 15:25, redoste wrote:
> On Mon Jul 7, 2025 at 11:35 CEST, Phillip Wood wrote:
>> On 07/07/2025 10:02, Patrick Steinhardt wrote:
>>> I think this exported environment variable now leaks into subsequent
>>> tests, doesn't it? We may want to do it in a subshell.
>>
>> That's a very good point.
> Sure thing, I took inspiration from the previous ssh-agent test and it
> exports the ssh-agent variables without spawning a subshell, so I
> figured it was fine, but it was only because test_when_finished will
> fail in a subshell.
> I guess it's probably fine to leak only the ssh-agent variables
> accross tests and keep TMPDIR in a subshell.

Hopefully having the ssh-agent variables set after the agent has been 
killed doesn't affect the later tests

>> The idiomatic way to test for an empty file is "test_file_is_empty
>> <file>" which avoids spawning wc.
> Thanks, I will update this.
> 
>> As this test is an abridged version of the other test that uses
>> ssh-agent I think it would be more efficient to tweak that test to check
>> there are no temporary files left over. Our test suite is slow and
>> tweaking an existing test to improve our coverage instead of adding a
>> new test means we don't make it any slower than necessary.
> I moved this test out of the other ssh-agent one according to the advice
> from brian on the previous version. I agree that spawning multiple
> ssh-agent is definitly not the best for speed, but is it worth it to
> make the test failure less clear?
test_file_is_empty will print a diagnostic message if it fails so it 
should be clear what has caused the test failure

> I feel like it's not the best to keep checks for temporary files clean
> up in a test that (initially) only claims to sign commits.

You can always tweak the test title if you want. The way I see it is 
that the changes that are being tested are related to commit signing as 
the invariant that we want to assert is that temporary files are cleaned 
up after signing commits.

Thanks

Phillip

  reply	other threads:[~2025-07-07 15:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-04 23:08 [PATCH] ssh signing: don't detach the filename strbuf from key_file tempfile redoste
2025-07-05 19:21 ` Jeff King
2025-07-05 20:07   ` brian m. carlson
2025-07-05 22:50     ` redoste
2025-07-05 23:04       ` redoste
2025-07-06  0:28       ` brian m. carlson
2025-07-06  3:13         ` Jeff King
2025-07-06 17:20           ` redoste
2025-07-06 17:14         ` redoste
2025-07-06 17:34 ` [PATCH v2] " redoste
2025-07-06 21:21   ` brian m. carlson
2025-07-07  9:02   ` Patrick Steinhardt
2025-07-07  9:35     ` Phillip Wood
2025-07-07 14:25       ` redoste
2025-07-07 15:26         ` Phillip Wood [this message]
2025-07-07 16:22           ` redoste
2025-07-07 16:42             ` Phillip Wood
2025-07-07 18:48 ` [PATCH v3] " redoste
2025-07-07 20:57   ` Junio C Hamano
2025-07-08  6:47     ` Patrick Steinhardt
2025-07-08 13:59       ` Phillip Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7130651b-76a6-4eb1-93cf-c9e237d398d7@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=fs@gigacodes.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=ps@pks.im \
    --cc=redoste@redoste.xyz \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).