Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Windows builds hang when the HEAD commit message is large (Invoke-Git deadlock)

Ouverte
  • Quelque chose ne va pas ?
#167 4 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

  • #168 par @tablackburn — fermée sans fusion

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
50/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
git, powershell
Domaine
build-system, ci-cd, tooling

Piste de recherche

Commencez par build.ps1 et le chemin Set-BuildEnvironment, puis examinez BuildHelpers\Invoke-Git et Get-BuildVariable pour confirmer comment le message de commit est lu. Reproduisez le blocage avec Invoke-Git log --format=%B -n 1 9720cb7 sous Windows et consultez #120 avant de choisir parmi les options d’atténuation listées. C’est terminé lorsque ./build.ps1 et Windows CI s’exécutent jusqu’au bout pour les messages HEAD volumineux, avec un test de régression couvrant un message plus grand que le tampon du tube.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug

Part of #120. Found while verifying the #162 merge.

Symptom

On Windows, Set-BuildEnvironment hangs forever when the HEAD commit message is large. Nothing
is printed, no error, no timeout — the build never starts.

This is currently happening on main. The push-triggered CI run for 9720cb7 hung both Windows
legs for 27+ minutes with zero output (ubuntu and macOS passed); I cancelled it. Every local
./build.ps1 on Windows hangs the same way, because build.ps1 calls Set-BuildEnvironment -Force before Invoke-psake.

Root cause

BuildHelpers\Invoke-Git (2.0.16) redirects both output streams and then waits for the process
to exit before reading them:

$pinfo.RedirectStandardError  = $RedirectStandardError   # $true
$pinfo.RedirectStandardOutput = $RedirectStandardOutput  # $true
...
$null = $p.Start()
$p.WaitForExit()                        # <-- blocks here
...
$stdout = $p.StandardOutput.ReadToEnd() # <-- never reached

When git writes more than the pipe buffer holds, git blocks waiting for someone to drain the
pipe, and Invoke-Git blocks waiting for git to exit. Neither can proceed. It is the textbook
WaitForExit-before-ReadToEnd deadlock described in the
ProcessStartInfo.RedirectStandardOutput remarks.

Get-BuildVariable calls it as Invoke-Git log --format=%B -n 1 <sha> to populate
$env:BHCommitMessage, so the payload is the full commit message body.

Reproduction

Measured on Windows 11, PowerShell 7.6.4, BuildHelpers 2.0.16, against real commits on main:

Commit Message size Result
f726f48 2617 bytes returns
64b7207 5498 bytes returns
9720cb7 5757 bytes hangs 
Import-Module BuildHelpers
Invoke-Git -Arguments 'log --format=%B -n 1 9720cb7'   # never returns on Windows

Linux and macOS have a larger pipe buffer and do not hit the threshold at these sizes, which is
why only the Windows legs hang.

Why CI did not catch it before merge

On a pull_request event, GitHub checks out a synthetic merge commit whose message is short
(Merge <sha> into <sha>). The real squash message only becomes HEAD on the push to main.
Every PR will be green and then hang main if its squashed body is large enough.

This repository writes long PR bodies and squash-merges them verbatim, so the trigger is not
exotic — it is the house style. #163 and #165 both have bodies over the threshold today.

Consumer impact

This is not only a repo-internal problem. Initialize-PSBuild calls Set-BuildEnvironment, so
any consumer building on Windows hangs when their own HEAD commit message crosses the threshold.
A hang with no output is a bad failure mode to ship at 1.0.0.

Options

  1. Stop passing the payload through Invoke-Git. Populate $env:BHCommitMessage ourselves
    before calling Set-BuildEnvironment, or truncate it. Narrow, immediate, ours to control
  2. Fix upstream. Read the streams asynchronously (BeginOutputReadLine, or ReadToEnd
    before WaitForExit) and PR it to BuildHelpers, then raise the RequiredModules floor once
    released. Correct fix, slowest path
  3. Trim squash commit messages at merge time. Pure process change, no code — but it depends
    on every future merge remembering, and it does nothing for consumers
  4. Drop the BuildHelpers dependency for this variable. Largest change; worth naming only
    because #120 already asks what 1.0.0 should depend on

Options 1 and 2 are not exclusive: 1 unblocks now, 2 fixes it for everyone.

Immediate mitigation

Until this is fixed, squash-merge with a short commit body on this repo. The full PR
description stays on the pull request either way.

Done when

./build.ps1 and Windows CI complete regardless of HEAD commit message size, with a regression
test covering a message larger than the pipe buffer.

Langage dominant
PowerShell
Étoiles
145
Forks
27
Aucune PR mergée en 30 j

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de psake/PowerShellBuild

Toutes les issues de psake/PowerShellBuild

Issues similaires

Plus d'issues Build System

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.