All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] ci(win+Meson): build in Release mode, avoiding t7001-mv hangs
Date: Mon, 28 Apr 2025 09:47:37 +0200	[thread overview]
Message-ID: <aA8ymUzWM2t0QkFP@pks.im> (raw)
In-Reply-To: <xmqqmsc4uv6d.fsf@gitster.g>

On Fri, Apr 25, 2025 at 08:18:02AM -0700, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > Since switching to `--vsenv`, the t7001-mv test consistently times out
> > after six hours in the CI builds on GitHub. This kind of waste is
> > inconsistent with my values.
> 
> With mine too and I would presume everybody else's.  I've been
> annoyed for a long time by one of those sharded Meson-Win test jobs
> that hang around until timeout.
> 
> Thank you very much for addressing the issue.

Indeed, thanks for fixing the issue! I haven't noticed these failing
jobs yet on my end, probably because on GitLab we only execute the
Win+Meson changes manually. Which is not great given that it makes me
miss issues with Meson like this.

I'll send a patch to run these tests by default so that I can see the
pain myself and address any issues that come up before others are forced
to.

> > The reason for this timeout is the test case 'nonsense mv triggers
> > assertion failure and partially updated index' in t7001-mv (which is
> > not even a regression test, but instead merely demonstrates a bug that
> > someone thought someone else should fix at some time). As the name
> > suggests, it triggers an assertion. The problem with this is that an
> > assertion on Windows, at least when run in Debug mode, will open a modal
> > dialog that patiently awaits some buttons to be clicked. Which never
> > happens in automated builds.
> 
> Interesting.
> 
> So another viable fix (no, I am not suggesting a counter-proposal,
> but asking a pure question to see if I understand the issue
> correctly) is to rewrite "assert(cond)" to "if (cond) BUG(...)"
> or something like that, so that it truly fails?

On the surface this sounds like a reasonable thing to do, but I don't
have enough context to be really able to tell.

> > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
> > index 83ca8e4182b..275240be5dc 100644
> > --- a/.github/workflows/main.yml
> > +++ b/.github/workflows/main.yml
> > @@ -265,7 +265,7 @@ jobs:
> >        run: pip install meson ninja
> >      - name: Setup
> >        shell: pwsh
> > -      run: meson setup build --vsenv -Dperl=disabled -Dcredential_helpers=wincred
> > +      run: meson setup build --vsenv -Dbuildtype=release -Dperl=disabled -Dcredential_helpers=wincred
> >      - name: Compile
> >        shell: pwsh
> >        run: meson compile -C build

So I'm fine with this trivial change as a band aid for now. The diff
looks obviously good to me.

Patrick

  reply	other threads:[~2025-04-28  7:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-25 15:05 [PATCH] ci(win+Meson): build in Release mode, avoiding t7001-mv hangs Johannes Schindelin via GitGitGadget
2025-04-25 15:18 ` Junio C Hamano
2025-04-28  7:47   ` Patrick Steinhardt [this message]
2025-04-28 17:01     ` Junio C Hamano
2025-04-29 12:20       ` Patrick Steinhardt
2025-04-29 20:48         ` Junio C Hamano
2025-04-30  8:58           ` Patrick Steinhardt
2025-04-30 12:46             ` Patrick Steinhardt
2025-04-29 20:57 ` Kristoffer Haugsbakk
2025-05-03 14:25 ` [PATCH v2] ci(win+Meson): build in Release mode Johannes Schindelin via GitGitGadget
2025-05-05  6:06   ` Patrick Steinhardt
2025-05-05  7:27     ` Johannes Schindelin
2025-05-05  9:43       ` Patrick Steinhardt
2025-05-05 15:54         ` Junio C Hamano
2025-05-06  7:57           ` Patrick Steinhardt
2025-05-06  8:32             ` Johannes Schindelin
2025-05-08 18:19               ` Junio C Hamano

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=aA8ymUzWM2t0QkFP@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.