Hi Junio, On Sat, 20 Aug 2022, Junio C Hamano wrote: > > As a first step towards enabling fsmonitor to work against > > network-mounted repos, a configuration option, 'fsmonitor.allowRemote' > > was introduced for Windows. Setting this option to true will override > > the default behavior (erroring-out) when a network-mounted repo is > > detected by fsmonitor. In order for macOS to have parity with Windows, > > the same option is now introduced for macOS. > > With this merged in, recent CI runs for 'seen' > > e.g. https://github.com/git/git/actions/runs/2892889122 > > seems to break macOS jobs, letting them hog CPU forever and exceed > 6hr or whatever the limit is. > > As an experiment I pushed out 'seen' but without this commit (not > the entire topic is excluded, the Windows one is still included). > As there is nothing specific to macOS between 'next' and 'seen', > macOS jobs seem to pass, which is not very surprising. > > https://github.com/git/git/actions/runs/2896207171 > > As the patch collected some review comments, I've already marked it > in the "What's cooking" draft as expecting a reroll of that step; > until that happens, let's keep it out of 'seen'. It makes sense to keep it out of `seen`, and at the same time I would like to encourage Eric to investigate what causes those time-outs. When toggling timestamps (click on the wheel on the upper right) at https://github.com/git/git/runs/7927812510?check_suite_focus=true#step:4:1774, it can be seen that at close to 1am, t9903 finished, but then nothing happens until twenty past 6am. I've downloaded the raw logs (also available via the wheel on the upper right) to find out which test timed out: $ diff -u \ <(sed -n 's/.*\] \(t[0-9][^ ]*\).*/\1/p' <~/Downloads/17 | sort) \ <(git ls-tree upstream/seen:t | cut -c 54- | grep '^t[0-9].*-.*sh$') --- /dev/fd/63 2022-08-22 14:56:05.510269527 +0200 +++ /dev/fd/62 2022-08-22 14:56:05.510269527 +0200 @@ -794,6 +794,7 @@ t7524-commit-summary.sh t7525-status-rename.sh t7526-commit-pathspec-file.sh +t7527-builtin-fsmonitor.sh t7528-signed-commit-ssh.sh t7600-merge.sh t7601-merge-pull-config.sh @@ -945,6 +946,7 @@ t9812-git-p4-wildcards.sh t9813-git-p4-preserve-users.sh t9814-git-p4-rename.sh +t9815-git-p4-submit-fail.sh t9816-git-p4-locked.sh t9817-git-p4-exclude.sh t9818-git-p4-block.sh @@ -964,5 +966,8 @@ t9832-unshelve.sh t9833-errors.sh t9834-git-p4-file-dir-bug.sh +t9835-git-p4-metadata-encoding-python2.sh +t9836-git-p4-metadata-encoding-python3.sh t9901-git-web--browse.sh +t9902-completion.sh t9903-bash-prompt.sh I have no idea what's up with t98* and t9902, but I would bet that they were somehow "swallowed" by `prove` being terminated, and that the actual test script that times out is t7527. Eric: To investigate, you will want to reproduce the problem on a macOS machine. If you have none available, you could create a temporary branch, heavily edit the CI definition, and push it to GitHub. And by heavy edits I mean something like this: - Remove all non-macOS jobs from `.github/workflows/main.yml` (that means removing all but the `regular` job, removing all but at least one `macos` matrix entry, and removing the the `needs: ci-config` and corresponding `if:` line. - Edit `t/Makefile` to define `T = t7527-builtin-fsmonitor.sh` instead of running all the tests. - Edit `.github/workflows/main.yml` so that the step that causes the time-out has a chance of timing out much sooner (and the subsequent steps then have a chance to upload the relevant logs): https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepstimeout-minutes If this does not shed any light into the issue, please let me know, I have a couple more aces up my sleeve. Ciao, Dscho
