{"thread":{"id":"57297","subject":"[PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","startedAt":"2022-01-24T19:01:38Z","lastAt":"2022-05-24T10:48:08Z","messageCount":98,"participants":["Johannes Schindelin via GitGitGadget","Eric Sunshine","Johannes Schindelin","Ævar Arnfjörð Bjarmason","Junio C Hamano","Phillip Wood","Victoria Dye","Victoria Dye via GitGitGadget"],"isPatch":true,"patchVersion":1,"patchTotal":9},"messages":[{"id":"446771","messageId":"pull.1117.git.1643050574.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":null,"subject":"[PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-01-24T18:56:05Z","receivedAt":"2022-01-24T19:01:38Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nBackground\n==========\n\nRecent patches intended to help readers figure out CI failures much quicker\nthan before. Unfortunately, they haven't been entirely positive for me. For\nexample, they broke the branch protections in Microsoft's fork of Git, where\nwe require Pull Requests to pass a certain set of Checks (which are\nidentified by their names) and therefore caused follow-up work.\n\nUsing CI and in general making it easier for new contributors is an area I'm\npassionate about, and one I'd like to see improved.\n\n\nThe current situation\n=====================\n\nLet me walk you through the current experience when a PR build fails: I get\na notification mail that only says that a certain job failed. There's no\nindication of which test failed (or was it the build?). I can click on a\nlink at it takes me to the workflow run. Once there, all it says is \"Process\ncompleted with exit code 1\", or even \"code 2\". Sure, I can click on one of\nthe failed jobs. It even expands the failed step's log (collapsing the other\nsteps). And what do I see there?\n\nLet's look at an example of a failed linux-clang (ubuntu-latest) job\n[https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true]:\n\n[...]\nTest Summary Report\n-------------------\nt1092-sparse-checkout-compatibility.sh           (Wstat: 256 Tests: 53 Failed: 1)\n  Failed test:  49\n  Non-zero exit status: 1\nt3701-add-interactive.sh                         (Wstat: 0 Tests: 71 Failed: 0)\n  TODO passed:   45, 47\nFiles=957, Tests=25489, 645 wallclock secs ( 5.74 usr  1.56 sys + 866.28 cusr 364.34 csys = 1237.92 CPU)\nResult: FAIL\nmake[1]: *** [Makefile:53: prove] Error 1\nmake[1]: Leaving directory '/home/runner/work/git/git/t'\nmake: *** [Makefile:3018: test] Error 2\n\n\nThat's it. I count myself lucky not to be a new contributor being faced with\nsomething like this.\n\nNow, since I am active in the Git project for a couple of days or so, I can\nmake sense of the \"TODO passed\" label and know that for the purpose of\nfixing the build failures, I need to ignore this, and that I need to focus\non the \"Failed test\" part instead.\n\nI also know that I do not have to get myself an ubuntu-latest box just to\nreproduce the error, I do not even have to check out the code and run it\njust to learn what that \"49\" means.\n\nI know, and I do not expect any new contributor, not even most seasoned\ncontributors to know, that I have to patiently collapse the \"Run\nci/run-build-and-tests.sh\" job's log, and instead expand the \"Run\nci/print-test-failures.sh\" job log (which did not fail and hence does not\ndraw any attention to it).\n\nI know, and again: I do not expect many others to know this, that I then\nhave to click into the \"Search logs\" box (not the regular web browser's\nsearch via Ctrl+F!) and type in \"not ok\" to find the log of the failed test\ncase (and this might still be a \"known broken\" one that is marked via\ntest_expect_failure and once again needs to be ignored).\n\nTo be excessively clear: This is not a great experience!\n\n\nImproved output\n===============\n\nOur previous Azure Pipelines-based CI builds had a much nicer UI, one that\neven showed flaky tests, and trends e.g. how long the test cases ran. When I\nported Git's CI over to GitHub workflows (to make CI more accessible to new\ncontributors), I knew fully well that we would leave this very nice UI\nbehind, and I had hoped that we would get something similar back via new,\ncommunity-contributed GitHub Actions that can be used in GitHub workflows.\nHowever, most likely because we use a home-grown test framework implemented\nin opinionated POSIX shells scripts, that did not happen.\n\nSo I had a look at what standards exist e.g. when testing PowerShell\nmodules, in the way of marking up their test output in GitHub workflows, and\nI was not disappointed: GitHub workflows support \"grouping\" of output lines,\ni.e. marking sections of the output as a group that is then collapsed by\ndefault and can be expanded. And it is this feature I decided to use in this\npatch series, along with GitHub workflows' commands to display errors or\nnotices that are also shown on the summary page of the workflow run. Now, in\naddition to \"Process completed with exit code\" on the summary page, we also\nread something like:\n\n⊗ linux-gcc (ubuntu-latest)\n   failed: t9800.20 submit from detached head\n\n\nEven better, this message is a link, and following that, the reader is\npresented with something like this\n[https://github.com/dscho/git/runs/4840190622?check_suite_focus=true]:\n\n⏵ Run ci/run-build-and-tests.sh\n⏵ CI setup\n  + ln -s /home/runner/none/.prove t/.prove\n  + run_tests=t\n  + export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n  + group Build make\n  + set +x\n⏵ Build\n⏵ Run tests\n  === Failed test: t9800-git-p4-basic ===\n⏵ ok: t9800.1 start p4d\n⏵ ok: t9800.2 add p4 files\n⏵ ok: t9800.3 basic git p4 clone\n⏵ ok: t9800.4 depot typo error\n⏵ ok: t9800.5 git p4 clone @all\n⏵ ok: t9800.6 git p4 sync uninitialized repo\n⏵ ok: t9800.7 git p4 sync new branch\n⏵ ok: t9800.8 clone two dirs\n⏵ ok: t9800.9 clone two dirs, @all\n⏵ ok: t9800.10 clone two dirs, @all, conflicting files\n⏵ ok: t9800.11 clone two dirs, each edited by submit, single git commit\n⏵ ok: t9800.12 clone using non-numeric revision ranges\n⏵ ok: t9800.13 clone with date range, excluding some changes\n⏵ ok: t9800.14 exit when p4 fails to produce marshaled output\n⏵ ok: t9800.15 exit gracefully for p4 server errors\n⏵ ok: t9800.16 clone --bare should make a bare repository\n⏵ ok: t9800.17 initial import time from top change time\n⏵ ok: t9800.18 unresolvable host in P4PORT should display error\n⏵ ok: t9800.19 run hook p4-pre-submit before submit\n  Error: failed: t9800.20 submit from detached head\n⏵ failure: t9800.20 submit from detached head \n  Error: failed: t9800.21 submit from worktree\n⏵ failure: t9800.21 submit from worktree \n  === Failed test: t9801-git-p4-branch ===\n  [...]\n\n\nThe \"Failed test:\" lines are colored in yellow to give a better visual clue\nabout the logs' structure, the \"Error:\" label is colored in red to draw the\nattention to the important part of the log, and the \"⏵\" characters indicate\nthat part of the log is collapsed and can be expanded by clicking on it.\n\nTo drill down, the reader merely needs to expand the (failed) test case's\nlog by clicking on it, and then study the log. If needed (e.g. when the test\ncase relies on side effects from previous test cases), the logs of preceding\ntest cases can be expanded as well. In this example, when expanding\nt9800.20, it looks like this (for ease of reading, I cut a few chunks of\nlines, indicated by \"[...]\"):\n\n[...]\n⏵ ok: t9800.19 run hook p4-pre-submit before submit\n  Error: failed: t9800.20 submit from detached head\n⏷ failure: t9800.20 submit from detached head \n      test_when_finished cleanup_git &&\n      git p4 clone --dest=\"$git\" //depot &&\n        (\n          cd \"$git\" &&\n          git checkout p4/master &&\n          >detached_head_test &&\n          git add detached_head_test &&\n          git commit -m \"add detached_head\" &&\n          git config git-p4.skipSubmitEdit true &&\n          git p4 submit &&\n            git p4 rebase &&\n            git log p4/master | grep detached_head\n        )\n    [...]\n    Depot paths: //depot/\n    Import destination: refs/remotes/p4/master\n    \n    Importing revision 9 (100%)Perforce db files in '.' will be created if missing...\n    Perforce db files in '.' will be created if missing...\n    \n    Traceback (most recent call last):\n      File \"/home/runner/work/git/git/git-p4\", line 4455, in <module>\n        main()\n      File \"/home/runner/work/git/git/git-p4\", line 4449, in main\n        if not cmd.run(args):\n      File \"/home/runner/work/git/git/git-p4\", line 2590, in run\n        rebase.rebase()\n      File \"/home/runner/work/git/git/git-p4\", line 4121, in rebase\n        if len(read_pipe(\"git diff-index HEAD --\")) > 0:\n      File \"/home/runner/work/git/git/git-p4\", line 297, in read_pipe\n        retcode, out, err = read_pipe_full(c, *k, **kw)\n      File \"/home/runner/work/git/git/git-p4\", line 284, in read_pipe_full\n        p = subprocess.Popen(\n      File \"/usr/lib/python3.8/subprocess.py\", line 858, in __init__\n        self._execute_child(args, executable, preexec_fn, close_fds,\n      File \"/usr/lib/python3.8/subprocess.py\", line 1704, in _execute_child\n        raise child_exception_type(errno_num, err_msg, err_filename)\n    FileNotFoundError: [Errno 2] No such file or directory: 'git diff-index HEAD --'\n    error: last command exited with $?=1\n    + cleanup_git\n    + retry_until_success rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + nr_tries_left=60\n    + rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + test_path_is_missing /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + test 1 -ne 1\n    + test -e /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + retry_until_success mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + nr_tries_left=60\n    + mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + exit 1\n    + eval_ret=1\n    + :\n    not ok 20 - submit from detached head\n    #    \n    #        test_when_finished cleanup_git &&\n    #        git p4 clone --dest=\"$git\" //depot &&\n    #        (\n    #            cd \"$git\" &&\n    #            git checkout p4/master &&\n    #            >detached_head_test &&\n    #            git add detached_head_test &&\n    #            git commit -m \"add detached_head\" &&\n    #            git config git-p4.skipSubmitEdit true &&\n    #            git p4 submit &&\n    #            git p4 rebase &&\n    #            git log p4/master | grep detached_head\n    #        )\n    #    \n  Error: failed: t9800.21 submit from worktree\n  [...]\n\n\nIs this the best UI we can have for test failures in CI runs? I hope we can\ndo better. Having said that, this patch series presents a pretty good start,\nand offers a basis for future improvements.\n\nJohannes Schindelin (9):\n  ci: fix code style\n  ci/run-build-and-tests: take a more high-level view\n  ci: make it easier to find failed tests' logs in the GitHub workflow\n  ci/run-build-and-tests: add some structure to the GitHub workflow\n    output\n  tests: refactor --write-junit-xml code\n  test(junit): avoid line feeds in XML attributes\n  ci: optionally mark up output in the GitHub workflow\n  ci: use `--github-workflow-markup` in the GitHub workflow\n  ci: call `finalize_test_case_output` a little later\n\n .github/workflows/main.yml           |  12 ---\n ci/lib.sh                            |  81 ++++++++++++++--\n ci/run-build-and-tests.sh            |  11 ++-\n ci/run-test-slice.sh                 |   5 +-\n t/test-lib-functions.sh              |   4 +-\n t/test-lib-github-workflow-markup.sh |  50 ++++++++++\n t/test-lib-junit.sh                  | 132 +++++++++++++++++++++++++++\n t/test-lib.sh                        | 128 ++++----------------------\n 8 files changed, 287 insertions(+), 136 deletions(-)\n create mode 100644 t/test-lib-github-workflow-markup.sh\n create mode 100644 t/test-lib-junit.sh\n\n\nbase-commit: af4e5f569bc89f356eb34a9373d7f82aca6faa8a\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1117%2Fdscho%2Fuse-grouping-in-ci-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1117/dscho/use-grouping-in-ci-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/1117\n-- \ngitgitgadget\n"},{"id":"446772","messageId":"db08b07c37a81866c63b062c92d9ee78976d1b34.1643050574.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"[PATCH 1/9] ci: fix code style","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-01-24T18:56:06Z","receivedAt":"2022-01-24T19:01:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nIn b92cb86ea14 (travis-ci: check that all build artifacts are\n.gitignore-d, 2017-12-31), a function was introduced with a code style\nthat is different from the surrounding code: it added the opening curly\nbrace on its own line, when all the existing functions in the same file\ncuddle that brace on the same line as the function name.\n\nLet's make the code style consistent again.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/lib.sh | 3 +--\n 1 file changed, 1 insertion(+), 2 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 9d28ab50fb4..ebb502640fa 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -69,8 +69,7 @@ skip_good_tree () {\n \texit 0\n }\n \n-check_unignored_build_artifacts ()\n-{\n+check_unignored_build_artifacts () {\n \t! git ls-files --other --exclude-standard --error-unmatch \\\n \t\t-- ':/*' 2>/dev/null ||\n \t{\n-- \ngitgitgadget\n\n"},{"id":"446773","messageId":"d2ff51bb5dacfe084166de106e9a864c902f0f36.1643050574.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"[PATCH 2/9] ci/run-build-and-tests: take a more high-level view","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-01-24T18:56:07Z","receivedAt":"2022-01-24T19:01:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nIn the web UI of GitHub workflows, failed runs are presented with the\njob step that failed auto-expanded. In the current setup, this is not\nhelpful at all because that shows only the output of `prove`, which says\nwhich test failed, but not in what way.\n\nWhat would help understand the reader what went wrong is the verbose\ntest output of the failed test.\n\nThe logs of the failed runs do contain that verbose test output, but it\nis shown in the _next_ step (which is marked as succeeding, and is\ntherefore _not_ auto-expanded). Anyone not intimately familiar with this\nwould completely miss the verbose test output, being left mostly\npuzzled with the test failures.\n\nWe are about to show the failed test cases' output in the _same_ step,\nso that the user has a much easier time to figure out what was going\nwrong.\n\nBut first, we must partially revert the change that tried to improve the\nCI runs by combining the `Makefile` targets to build into a single\n`make` invocation. That might have sounded like a good idea at the time,\nbut it does make it rather impossible for the CI script to determine\nwhether the _build_ failed, or the _tests_. If the tests were run at\nall, that is.\n\nSo let's go back to calling `make` for the build, and call `make test`\nseparately so that we can easily detect that _that_ invocation failed,\nand react appropriately.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/run-build-and-tests.sh | 10 +++++++---\n 1 file changed, 7 insertions(+), 3 deletions(-)\n\ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex 280dda7d285..b70373c172f 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -10,7 +10,7 @@ windows*) cmd //c mklink //j t\\\\.prove \"$(cygpath -aw \"$cache_dir/.prove\")\";;\n *) ln -s \"$cache_dir/.prove\" t/.prove;;\n esac\n \n-export MAKE_TARGETS=\"all test\"\n+run_tests=t\n \n case \"$jobname\" in\n linux-gcc)\n@@ -41,14 +41,18 @@ pedantic)\n \t# Don't run the tests; we only care about whether Git can be\n \t# built.\n \texport DEVOPTS=pedantic\n-\texport MAKE_TARGETS=all\n+\trun_tests=\n \t;;\n esac\n \n # Any new \"test\" targets should not go after this \"make\", but should\n # adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n # start running tests.\n-make $MAKE_TARGETS\n+make\n+if test -n \"$run_tests\"\n+then\n+\tmake test\n+fi\n check_unignored_build_artifacts\n \n save_good_tree\n-- \ngitgitgadget\n\n"},{"id":"446774","messageId":"98891b0d3f7927086350cc9523736ae2eb7c1ee2.1643050574.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"[PATCH 3/9] ci: make it easier to find failed tests' logs in the GitHub workflow","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-01-24T18:56:08Z","receivedAt":"2022-01-24T19:01:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nYou currently have to know a lot of implementation details when\ninvestigating test failures in the CI runs. The first step is easy: the\nfailed job is marked quite clearly, but when opening it, the failed step\nis expanded, which in our case is the one running\n`ci/run-build-and-tests.sh`. This step, most notably, only offers a\nhigh-level view of what went wrong: it prints the output of `prove`\nwhich merely tells the reader which test script failed.\n\nThe actually interesting part is in the detailed log of said failed\ntest script. But that log is shown in the CI run's step that runs\n`ci/print-test-failures.sh`. And that step is _not_ expanded in the web\nUI by default.\n\nLet's help the reader by showing the failed tests' detailed logs in the\nstep that is expanded automatically, i.e. directly after the test suite\nfailed.\n\nThis also helps the situation where the _build_ failed and the\n`print-test-failures` step was executed under the assumption that the\n_test suite_ failed, and consequently failed to find any failed tests.\n\nAn alternative way to implement this patch would be to source\n`ci/print-test-failures.sh` in the `handle_test_failures` function to\nshow these logs. However, over the course of the next few commits, we\nwant to introduce some grouping which would be harder to achieve that\nway (for example, we do want a leaner, and colored, preamble for each\nfailed test script, and it would be trickier to accommodate the lack of\nnested groupings in GitHub workflows' output).\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n .github/workflows/main.yml | 12 ------------\n ci/lib.sh                  | 23 +++++++++++++++++++++++\n ci/run-build-and-tests.sh  |  3 ++-\n ci/run-test-slice.sh       |  3 ++-\n 4 files changed, 27 insertions(+), 14 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex c35200defb9..3fa88b78b6d 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -119,10 +119,6 @@ jobs:\n     - name: test\n       shell: bash\n       run: . /etc/profile && ci/run-test-slice.sh ${{matrix.nr}} 10\n-    - name: ci/print-test-failures.sh\n-      if: failure()\n-      shell: bash\n-      run: ci/print-test-failures.sh\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v2\n@@ -204,10 +200,6 @@ jobs:\n       env:\n         NO_SVN_TESTS: 1\n       run: . /etc/profile && ci/run-test-slice.sh ${{matrix.nr}} 10\n-    - name: ci/print-test-failures.sh\n-      if: failure()\n-      shell: bash\n-      run: ci/print-test-failures.sh\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v2\n@@ -261,8 +253,6 @@ jobs:\n     - uses: actions/checkout@v2\n     - run: ci/install-dependencies.sh\n     - run: ci/run-build-and-tests.sh\n-    - run: ci/print-test-failures.sh\n-      if: failure()\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v2\n@@ -292,8 +282,6 @@ jobs:\n     - uses: actions/checkout@v1\n     - run: ci/install-docker-dependencies.sh\n     - run: ci/run-build-and-tests.sh\n-    - run: ci/print-test-failures.sh\n-      if: failure()\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v1\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex ebb502640fa..2b2c0932320 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -78,6 +78,10 @@ check_unignored_build_artifacts () {\n \t}\n }\n \n+handle_failed_tests () {\n+\treturn 1\n+}\n+\n # GitHub Action doesn't set TERM, which is required by tput\n export TERM=${TERM:-dumb}\n \n@@ -123,6 +127,25 @@ then\n \tCI_JOB_ID=\"$GITHUB_RUN_ID\"\n \tCC=\"${CC:-gcc}\"\n \tDONT_SKIP_TAGS=t\n+\thandle_failed_tests () {\n+\t\tmkdir -p t/failed-test-artifacts\n+\t\techo \"FAILED_TEST_ARTIFACTS=t/failed-test-artifacts\" >>$GITHUB_ENV\n+\n+\t\tfor test_exit in t/test-results/*.exit\n+\t\tdo\n+\t\t\ttest 0 != \"$(cat \"$test_exit\")\" || continue\n+\n+\t\t\ttest_name=\"${test_exit%.exit}\"\n+\t\t\ttest_name=\"${test_name##*/}\"\n+\t\t\tprintf \"\\\\e[33m\\\\e[1m=== Failed test: ${test_name} ===\\\\e[m\\\\n\"\n+\t\t\tcat \"t/test-results/$test_name.out\"\n+\n+\t\t\ttrash_dir=\"t/trash directory.$test_name\"\n+\t\t\tcp \"t/test-results/$test_name.out\" t/failed-test-artifacts/\n+\t\t\ttar czf t/failed-test-artifacts/\"$test_name\".trash.tar.gz \"$trash_dir\"\n+\t\tdone\n+\t\treturn 1\n+\t}\n \n \tcache_dir=\"$HOME/none\"\n \ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex b70373c172f..e49f9eaa8c0 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -51,7 +51,8 @@ esac\n make\n if test -n \"$run_tests\"\n then\n-\tmake test\n+\tmake test ||\n+\thandle_failed_tests\n fi\n check_unignored_build_artifacts\n \ndiff --git a/ci/run-test-slice.sh b/ci/run-test-slice.sh\nindex f8c2c3106a2..63358c23e11 100755\n--- a/ci/run-test-slice.sh\n+++ b/ci/run-test-slice.sh\n@@ -12,6 +12,7 @@ esac\n \n make --quiet -C t T=\"$(cd t &&\n \t./helper/test-tool path-utils slice-tests \"$1\" \"$2\" t[0-9]*.sh |\n-\ttr '\\n' ' ')\"\n+\ttr '\\n' ' ')\" ||\n+handle_failed_tests\n \n check_unignored_build_artifacts\n-- \ngitgitgadget\n\n"},{"id":"446775","messageId":"9333ba781b8240f704e739b00d274f8c3d887e39.1643050574.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"[PATCH 4/9] ci/run-build-and-tests: add some structure to the GitHub workflow output","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-01-24T18:56:09Z","receivedAt":"2022-01-24T19:01:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nThe current output of Git's GitHub workflow can be quite confusing,\nespecially for contributors new to the project.\n\nTo make it more helpful, let's introduce some collapsible grouping.\nInitially, readers will see the high-level view of what actually\nhappened (did the build fail, or the test suite?). To drill down, the\nrespective group can be expanded.\n\nNote: sadly, workflow output currently cannot contain any nested groups\n(see https://github.com/actions/runner/issues/802 for details),\ntherefore we take pains to ensure to end any previous group before\nstarting a new one.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/lib.sh                 | 55 ++++++++++++++++++++++++++++++++++-----\n ci/run-build-and-tests.sh |  4 +--\n ci/run-test-slice.sh      |  2 +-\n 3 files changed, 51 insertions(+), 10 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 2b2c0932320..4ed8f40ab02 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -1,5 +1,49 @@\n # Library of functions shared by all CI scripts\n \n+if test true != \"$GITHUB_ACTIONS\"\n+then\n+\tbegin_group () { :; }\n+\tend_group () { :; }\n+\n+\tgroup () {\n+\t\tshift\n+\t\t\"$@\"\n+\t}\n+\tset -x\n+else\n+\tbegin_group () {\n+\t\tneed_to_end_group=t\n+\t\techo \"::group::$1\" >&2\n+\t\tset -x\n+\t}\n+\n+\tend_group () {\n+\t\ttest -n \"$need_to_end_group\" || return 0\n+\t\tset +x\n+\t\tneed_to_end_group=\n+\t\techo '::endgroup::' >&2\n+\t}\n+\ttrap end_group EXIT\n+\n+\tgroup () {\n+\t\tset +x\n+\t\tbegin_group \"$1\"\n+\t\tshift\n+\t\t\"$@\"\n+\t\tres=$?\n+\t\tend_group\n+\t\treturn $res\n+\t}\n+\n+\tbegin_group \"CI setup\"\n+fi\n+\n+# Set 'exit on error' for all CI scripts to let the caller know that\n+# something went wrong.\n+# Set tracing executed commands, primarily setting environment variables\n+# and installing dependencies.\n+set -e\n+\n skip_branch_tip_with_tag () {\n \t# Sometimes, a branch is pushed at the same time the tag that points\n \t# at the same commit as the tip of the branch is pushed, and building\n@@ -88,12 +132,6 @@ export TERM=${TERM:-dumb}\n # Clear MAKEFLAGS that may come from the outside world.\n export MAKEFLAGS=\n \n-# Set 'exit on error' for all CI scripts to let the caller know that\n-# something went wrong.\n-# Set tracing executed commands, primarily setting environment variables\n-# and installing dependencies.\n-set -ex\n-\n if test -n \"$SYSTEM_COLLECTIONURI\" || test -n \"$SYSTEM_TASKDEFINITIONSURI\"\n then\n \tCI_TYPE=azure-pipelines\n@@ -138,7 +176,7 @@ then\n \t\t\ttest_name=\"${test_exit%.exit}\"\n \t\t\ttest_name=\"${test_name##*/}\"\n \t\t\tprintf \"\\\\e[33m\\\\e[1m=== Failed test: ${test_name} ===\\\\e[m\\\\n\"\n-\t\t\tcat \"t/test-results/$test_name.out\"\n+\t\t\tgroup \"Failed test: $test_name\" cat \"t/test-results/$test_name.out\"\n \n \t\t\ttrash_dir=\"t/trash directory.$test_name\"\n \t\t\tcp \"t/test-results/$test_name.out\" t/failed-test-artifacts/\n@@ -234,3 +272,6 @@ linux-leaks)\n esac\n \n MAKEFLAGS=\"$MAKEFLAGS CC=${CC:-cc}\"\n+\n+end_group\n+set -x\ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex e49f9eaa8c0..5516f45f7fe 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -48,10 +48,10 @@ esac\n # Any new \"test\" targets should not go after this \"make\", but should\n # adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n # start running tests.\n-make\n+group Build make\n if test -n \"$run_tests\"\n then\n-\tmake test ||\n+\tgroup \"Run tests\" make test ||\n \thandle_failed_tests\n fi\n check_unignored_build_artifacts\ndiff --git a/ci/run-test-slice.sh b/ci/run-test-slice.sh\nindex 63358c23e11..a3c67956a8d 100755\n--- a/ci/run-test-slice.sh\n+++ b/ci/run-test-slice.sh\n@@ -10,7 +10,7 @@ windows*) cmd //c mklink //j t\\\\.prove \"$(cygpath -aw \"$cache_dir/.prove\")\";;\n *) ln -s \"$cache_dir/.prove\" t/.prove;;\n esac\n \n-make --quiet -C t T=\"$(cd t &&\n+group \"Run tests\" make --quiet -C t T=\"$(cd t &&\n \t./helper/test-tool path-utils slice-tests \"$1\" \"$2\" t[0-9]*.sh |\n \ttr '\\n' ' ')\" ||\n handle_failed_tests\n-- \ngitgitgadget\n\n"},{"id":"446776","messageId":"94dcbe1bc437dc9738cfc635e9085d743eb4ec98.1643050574.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"[PATCH 5/9] tests: refactor --write-junit-xml code","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-01-24T18:56:10Z","receivedAt":"2022-01-24T19:01:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nThe code writing JUnit XML is interspersed directly with all the code in\n`t/test-lib.sh`, and it is therefore not only ill-separated, but\nintroducing yet another output format would make the situation even\nworse.\n\nLet's introduce an abstraction layer by hiding the JUnit XML code behind\nfour new functions that are supposed to be called before and after each\ntest and test case.\n\nThis is not just an academic exercise, refactoring for refactoring's\nsake. We _actually_ want to introduce such a new output format, to\nmake it substantially easier to diagnose test failures in our GitHub\nworkflow, therefore we do need this refactoring.\n\nThis commit is best viewed with `git show --color-moved\n--color-moved-ws=allow-indentation-change <commit>`.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib-junit.sh | 126 ++++++++++++++++++++++++++++++++++++++++++++\n t/test-lib.sh       | 124 ++++++-------------------------------------\n 2 files changed, 142 insertions(+), 108 deletions(-)\n create mode 100644 t/test-lib-junit.sh\n\ndiff --git a/t/test-lib-junit.sh b/t/test-lib-junit.sh\nnew file mode 100644\nindex 00000000000..9d55d74d764\n--- /dev/null\n+++ b/t/test-lib-junit.sh\n@@ -0,0 +1,126 @@\n+# Library of functions to format test scripts' output in JUnit XML\n+# format, to support Git's test suite result to be presented in an\n+# easily digestible way on Azure Pipelines.\n+#\n+# Copyright (c) 2022 Johannes Schindelin\n+#\n+# This program is free software: you can redistribute it and/or modify\n+# it under the terms of the GNU General Public License as published by\n+# the Free Software Foundation, either version 2 of the License, or\n+# (at your option) any later version.\n+#\n+# This program is distributed in the hope that it will be useful,\n+# but WITHOUT ANY WARRANTY; without even the implied warranty of\n+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n+# GNU General Public License for more details.\n+#\n+# You should have received a copy of the GNU General Public License\n+# along with this program.  If not, see http://www.gnu.org/licenses/ .\n+#\n+# The idea is for `test-lib.sh` to source this file when the user asks\n+# for JUnit XML; these functions will then override (empty) functions\n+# that are are called at the appropriate times during the test runs.\n+\n+start_test_output () {\n+\tjunit_xml_dir=\"$TEST_OUTPUT_DIRECTORY/out\"\n+\tmkdir -p \"$junit_xml_dir\"\n+\tjunit_xml_base=${1##*/}\n+\tjunit_xml_path=\"$junit_xml_dir/TEST-${junit_xml_base%.sh}.xml\"\n+\tjunit_attrs=\"name=\\\"${junit_xml_base%.sh}\\\"\"\n+\tjunit_attrs=\"$junit_attrs timestamp=\\\"$(TZ=UTC \\\n+\t\tdate +%Y-%m-%dT%H:%M:%S)\\\"\"\n+\twrite_junit_xml --truncate \"<testsuites>\" \"  <testsuite $junit_attrs>\"\n+\tjunit_suite_start=$(test-tool date getnanos)\n+\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n+\tthen\n+\t\tGIT_TEST_TEE_OFFSET=0\n+\tfi\n+}\n+\n+start_test_case_output () {\n+\tjunit_start=$(test-tool date getnanos)\n+}\n+\n+finalize_test_case_output () {\n+\ttest_case_result=$1\n+\tshift\n+\tcase \"$test_case_result\" in\n+\tok)\n+\t\tset \"$*\"\n+\t\t;;\n+\tfailure)\n+\t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n+\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \"$1\")\\\">\"\n+\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \\\n+\t\t\t\"$(if test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n+\t\t\t   then\n+\t\t\t\ttest-tool path-utils skip-n-bytes \\\n+\t\t\t\t\t\"$GIT_TEST_TEE_OUTPUT_FILE\" $GIT_TEST_TEE_OFFSET\n+\t\t\t   else\n+\t\t\t\tprintf '%s\\n' \"$@\" | sed 1d\n+\t\t\t   fi)\")\"\n+\t\tjunit_insert=\"$junit_insert</failure>\"\n+\t\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n+\t\tthen\n+\t\t\tjunit_insert=\"$junit_insert<system-err>$(xml_attr_encode \\\n+\t\t\t\t\"$(cat \"$GIT_TEST_TEE_OUTPUT_FILE\")\")</system-err>\"\n+\t\tfi\n+\t\tset \"$1\" \"      $junit_insert\"\n+\t\t;;\n+\tfixed)\n+\t\tset \"$* (breakage fixed)\"\n+\t\t;;\n+\tbroken)\n+\t\tset \"$* (known breakage)\"\n+\t\t;;\n+\tskip)\n+\t\tmessage=\"$(xml_attr_encode \"$skipped_reason\")\"\n+\t\tset \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n+\t\t;;\n+\tesac\n+\n+\tjunit_attrs=\"name=\\\"$(xml_attr_encode \"$this_test.$test_count $1\")\\\"\"\n+\tshift\n+\tjunit_attrs=\"$junit_attrs classname=\\\"$this_test\\\"\"\n+\tjunit_attrs=\"$junit_attrs time=\\\"$(test-tool \\\n+\t\tdate getnanos $junit_start)\\\"\"\n+\twrite_junit_xml \"$(printf '%s\\n' \\\n+\t\t\"    <testcase $junit_attrs>\" \"$@\" \"    </testcase>\")\"\n+\tjunit_have_testcase=t\n+}\n+\n+finalize_test_output () {\n+\tif test -n \"$junit_xml_path\"\n+\tthen\n+\t\ttest -n \"$junit_have_testcase\" || {\n+\t\t\tjunit_start=$(test-tool date getnanos)\n+\t\t\twrite_junit_xml_testcase \"all tests skipped\"\n+\t\t}\n+\n+\t\t# adjust the overall time\n+\t\tjunit_time=$(test-tool date getnanos $junit_suite_start)\n+\t\tsed -e \"s/\\(<testsuite.*\\) time=\\\"[^\\\"]*\\\"/\\1/\" \\\n+\t\t\t-e \"s/<testsuite [^>]*/& time=\\\"$junit_time\\\"/\" \\\n+\t\t\t-e '/^ *<\\/testsuite/d' \\\n+\t\t\t<\"$junit_xml_path\" >\"$junit_xml_path.new\"\n+\t\tmv \"$junit_xml_path.new\" \"$junit_xml_path\"\n+\n+\t\twrite_junit_xml \"  </testsuite>\" \"</testsuites>\"\n+\t\twrite_junit_xml=\n+\tfi\n+}\n+\n+write_junit_xml () {\n+\tcase \"$1\" in\n+\t--truncate)\n+\t\t>\"$junit_xml_path\"\n+\t\tjunit_have_testcase=\n+\t\tshift\n+\t\t;;\n+\tesac\n+\tprintf '%s\\n' \"$@\" >>\"$junit_xml_path\"\n+}\n+\n+xml_attr_encode () {\n+\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n+}\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 0f7a137c7d8..e13e1cb9124 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -107,6 +107,12 @@ mark_option_requires_arg () {\n \tstore_arg_to=$2\n }\n \n+# These functions can be overridden e.g. to output JUnit XML\n+start_test_output () { :; }\n+start_test_case_output () { :; }\n+finalize_test_case_output () { :; }\n+finalize_test_output () { :; }\n+\n parse_option () {\n \tlocal opt=\"$1\"\n \n@@ -166,7 +172,7 @@ parse_option () {\n \t\ttee=t\n \t\t;;\n \t--write-junit-xml)\n-\t\twrite_junit_xml=t\n+\t\t. \"$TEST_DIRECTORY/test-lib-junit.sh\"\n \t\t;;\n \t--stress)\n \t\tstress=t ;;\n@@ -613,7 +619,7 @@ exec 6<&0\n exec 7>&2\n \n _error_exit () {\n-\tfinalize_junit_xml\n+\tfinalize_test_output\n \tGIT_EXIT_OK=t\n \texit 1\n }\n@@ -723,35 +729,13 @@ trap '{ code=$?; set +x; } 2>/dev/null; exit $code' INT TERM HUP\n # the test_expect_* functions instead.\n \n test_ok_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\twrite_junit_xml_testcase \"$*\"\n-\tfi\n+\tfinalize_test_case_output ok \"$@\"\n \ttest_success=$(($test_success + 1))\n \tsay_color \"\" \"ok $test_count - $@\"\n }\n \n test_failure_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n-\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \"$1\")\\\">\"\n-\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \\\n-\t\t\t\"$(if test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n-\t\t\t   then\n-\t\t\t\ttest-tool path-utils skip-n-bytes \\\n-\t\t\t\t\t\"$GIT_TEST_TEE_OUTPUT_FILE\" $GIT_TEST_TEE_OFFSET\n-\t\t\t   else\n-\t\t\t\tprintf '%s\\n' \"$@\" | sed 1d\n-\t\t\t   fi)\")\"\n-\t\tjunit_insert=\"$junit_insert</failure>\"\n-\t\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n-\t\tthen\n-\t\t\tjunit_insert=\"$junit_insert<system-err>$(xml_attr_encode \\\n-\t\t\t\t\"$(cat \"$GIT_TEST_TEE_OUTPUT_FILE\")\")</system-err>\"\n-\t\tfi\n-\t\twrite_junit_xml_testcase \"$1\" \"      $junit_insert\"\n-\tfi\n+\tfinalize_test_case_output failure \"$@\"\n \ttest_failure=$(($test_failure + 1))\n \tsay_color error \"not ok $test_count - $1\"\n \tshift\n@@ -760,19 +744,13 @@ test_failure_ () {\n }\n \n test_known_broken_ok_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\twrite_junit_xml_testcase \"$* (breakage fixed)\"\n-\tfi\n+\tfinalize_test_case_output fixed \"$@\"\n \ttest_fixed=$(($test_fixed+1))\n \tsay_color error \"ok $test_count - $@ # TODO known breakage vanished\"\n }\n \n test_known_broken_failure_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\twrite_junit_xml_testcase \"$* (known breakage)\"\n-\tfi\n+\tfinalize_test_case_output broken \"$@\"\n \ttest_broken=$(($test_broken+1))\n \tsay_color warn \"not ok $test_count - $@ # TODO known breakage\"\n }\n@@ -1049,10 +1027,7 @@ test_start_ () {\n \ttest_count=$(($test_count+1))\n \tmaybe_setup_verbose\n \tmaybe_setup_valgrind\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\tjunit_start=$(test-tool date getnanos)\n-\tfi\n+\tstart_test_case_output\n }\n \n test_finish_ () {\n@@ -1103,12 +1078,7 @@ test_skip () {\n \n \tcase \"$to_skip\" in\n \tt)\n-\t\tif test -n \"$write_junit_xml\"\n-\t\tthen\n-\t\t\tmessage=\"$(xml_attr_encode \"$skipped_reason\")\"\n-\t\t\twrite_junit_xml_testcase \"$1\" \\\n-\t\t\t\t\"      <skipped message=\\\"$message\\\" />\"\n-\t\tfi\n+\t\tfinalize_test_case_output skip \"$@\"\n \n \t\tsay_color skip \"ok $test_count # skip $1 ($skipped_reason)\"\n \t\t: true\n@@ -1124,53 +1094,6 @@ test_at_end_hook_ () {\n \t:\n }\n \n-write_junit_xml () {\n-\tcase \"$1\" in\n-\t--truncate)\n-\t\t>\"$junit_xml_path\"\n-\t\tjunit_have_testcase=\n-\t\tshift\n-\t\t;;\n-\tesac\n-\tprintf '%s\\n' \"$@\" >>\"$junit_xml_path\"\n-}\n-\n-xml_attr_encode () {\n-\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n-}\n-\n-write_junit_xml_testcase () {\n-\tjunit_attrs=\"name=\\\"$(xml_attr_encode \"$this_test.$test_count $1\")\\\"\"\n-\tshift\n-\tjunit_attrs=\"$junit_attrs classname=\\\"$this_test\\\"\"\n-\tjunit_attrs=\"$junit_attrs time=\\\"$(test-tool \\\n-\t\tdate getnanos $junit_start)\\\"\"\n-\twrite_junit_xml \"$(printf '%s\\n' \\\n-\t\t\"    <testcase $junit_attrs>\" \"$@\" \"    </testcase>\")\"\n-\tjunit_have_testcase=t\n-}\n-\n-finalize_junit_xml () {\n-\tif test -n \"$write_junit_xml\" && test -n \"$junit_xml_path\"\n-\tthen\n-\t\ttest -n \"$junit_have_testcase\" || {\n-\t\t\tjunit_start=$(test-tool date getnanos)\n-\t\t\twrite_junit_xml_testcase \"all tests skipped\"\n-\t\t}\n-\n-\t\t# adjust the overall time\n-\t\tjunit_time=$(test-tool date getnanos $junit_suite_start)\n-\t\tsed -e \"s/\\(<testsuite.*\\) time=\\\"[^\\\"]*\\\"/\\1/\" \\\n-\t\t\t-e \"s/<testsuite [^>]*/& time=\\\"$junit_time\\\"/\" \\\n-\t\t\t-e '/^ *<\\/testsuite/d' \\\n-\t\t\t<\"$junit_xml_path\" >\"$junit_xml_path.new\"\n-\t\tmv \"$junit_xml_path.new\" \"$junit_xml_path\"\n-\n-\t\twrite_junit_xml \"  </testsuite>\" \"</testsuites>\"\n-\t\twrite_junit_xml=\n-\tfi\n-}\n-\n test_atexit_cleanup=:\n test_atexit_handler () {\n \t# In a succeeding test script 'test_atexit_handler' is invoked\n@@ -1193,7 +1116,7 @@ test_done () {\n \t# removed, so the commands can access pidfiles and socket files.\n \ttest_atexit_handler\n \n-\tfinalize_junit_xml\n+\tfinalize_test_output\n \n \tif test -z \"$HARNESS_ACTIVE\"\n \tthen\n@@ -1484,22 +1407,7 @@ fi\n # in subprocesses like git equals our $PWD (for pathname comparisons).\n cd -P \"$TRASH_DIRECTORY\" || exit 1\n \n-if test -n \"$write_junit_xml\"\n-then\n-\tjunit_xml_dir=\"$TEST_OUTPUT_DIRECTORY/out\"\n-\tmkdir -p \"$junit_xml_dir\"\n-\tjunit_xml_base=${0##*/}\n-\tjunit_xml_path=\"$junit_xml_dir/TEST-${junit_xml_base%.sh}.xml\"\n-\tjunit_attrs=\"name=\\\"${junit_xml_base%.sh}\\\"\"\n-\tjunit_attrs=\"$junit_attrs timestamp=\\\"$(TZ=UTC \\\n-\t\tdate +%Y-%m-%dT%H:%M:%S)\\\"\"\n-\twrite_junit_xml --truncate \"<testsuites>\" \"  <testsuite $junit_attrs>\"\n-\tjunit_suite_start=$(test-tool date getnanos)\n-\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n-\tthen\n-\t\tGIT_TEST_TEE_OFFSET=0\n-\tfi\n-fi\n+start_test_output \"$0\"\n \n # Convenience\n # A regexp to match 5 and 35 hexdigits\n-- \ngitgitgadget\n\n"},{"id":"446777","messageId":"41230100091e3c53fa87516c9db697ad385d5873.1643050574.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"[PATCH 6/9] test(junit): avoid line feeds in XML attributes","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-01-24T18:56:11Z","receivedAt":"2022-01-24T19:01:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nIn the test case's output, we do want newline characters, but in the XML\nattributes we do not want them.\n\nHowever, the `xml_attr_encode` function always adds a Line Feed at the\nend (which are then encoded as `&#x0a;`, even for XML attributes.\n\nThis seems not to faze Azure Pipelines' XML parser, but it still is\nincorrect, so let's fix it.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib-junit.sh | 14 ++++++++++----\n 1 file changed, 10 insertions(+), 4 deletions(-)\n\ndiff --git a/t/test-lib-junit.sh b/t/test-lib-junit.sh\nindex 9d55d74d764..c959183c7e2 100644\n--- a/t/test-lib-junit.sh\n+++ b/t/test-lib-junit.sh\n@@ -50,7 +50,7 @@ finalize_test_case_output () {\n \t\t;;\n \tfailure)\n \t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n-\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \"$1\")\\\">\"\n+\t\tjunit_insert=\"$junit_insert $(xml_attr_encode --no-lf \"$1\")\\\">\"\n \t\tjunit_insert=\"$junit_insert $(xml_attr_encode \\\n \t\t\t\"$(if test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n \t\t\t   then\n@@ -74,12 +74,12 @@ finalize_test_case_output () {\n \t\tset \"$* (known breakage)\"\n \t\t;;\n \tskip)\n-\t\tmessage=\"$(xml_attr_encode \"$skipped_reason\")\"\n+\t\tmessage=\"$(xml_attr_encode --no-lf \"$skipped_reason\")\"\n \t\tset \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n \t\t;;\n \tesac\n \n-\tjunit_attrs=\"name=\\\"$(xml_attr_encode \"$this_test.$test_count $1\")\\\"\"\n+\tjunit_attrs=\"name=\\\"$(xml_attr_encode --no-lf \"$this_test.$test_count $1\")\\\"\"\n \tshift\n \tjunit_attrs=\"$junit_attrs classname=\\\"$this_test\\\"\"\n \tjunit_attrs=\"$junit_attrs time=\\\"$(test-tool \\\n@@ -122,5 +122,11 @@ write_junit_xml () {\n }\n \n xml_attr_encode () {\n-\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n+\tif test \"x$1\" = \"x--no-lf\"\n+\tthen\n+\t\tshift\n+\t\tprintf '%s' \"$*\" | test-tool xml-encode\n+\telse\n+\t\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n+\tfi\n }\n-- \ngitgitgadget\n\n"},{"id":"446778","messageId":"992b157588975803faf6747cca94f197611fc5c5.1643050574.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"[PATCH 9/9] ci: call `finalize_test_case_output` a little later","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-01-24T18:56:14Z","receivedAt":"2022-01-24T19:02:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nWe used to call that function already before printing the final verdict.\nHowever, now that we added grouping to the GitHub workflow output, we\nwill want to include even that part in the collapsible group for that\ntest case.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib.sh | 11 ++++++-----\n 1 file changed, 6 insertions(+), 5 deletions(-)\n\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 076bee58c19..1e683ad879b 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -732,30 +732,31 @@ trap '{ code=$?; set +x; } 2>/dev/null; exit $code' INT TERM HUP\n # the test_expect_* functions instead.\n \n test_ok_ () {\n-\tfinalize_test_case_output ok \"$@\"\n \ttest_success=$(($test_success + 1))\n \tsay_color \"\" \"ok $test_count - $@\"\n+\tfinalize_test_case_output ok \"$@\"\n }\n \n test_failure_ () {\n-\tfinalize_test_case_output failure \"$@\"\n+\tfailure_label=$1\n \ttest_failure=$(($test_failure + 1))\n \tsay_color error \"not ok $test_count - $1\"\n \tshift\n \tprintf '%s\\n' \"$*\" | sed -e 's/^/#\t/'\n \ttest \"$immediate\" = \"\" || _error_exit\n+\tfinalize_test_case_output failure \"$failure_label\" \"$@\"\n }\n \n test_known_broken_ok_ () {\n-\tfinalize_test_case_output fixed \"$@\"\n \ttest_fixed=$(($test_fixed+1))\n \tsay_color error \"ok $test_count - $@ # TODO known breakage vanished\"\n+\tfinalize_test_case_output fixed \"$@\"\n }\n \n test_known_broken_failure_ () {\n-\tfinalize_test_case_output broken \"$@\"\n \ttest_broken=$(($test_broken+1))\n \tsay_color warn \"not ok $test_count - $@ # TODO known breakage\"\n+\tfinalize_test_case_output broken \"$@\"\n }\n \n test_debug () {\n@@ -1081,10 +1082,10 @@ test_skip () {\n \n \tcase \"$to_skip\" in\n \tt)\n-\t\tfinalize_test_case_output skip \"$@\"\n \n \t\tsay_color skip \"ok $test_count # skip $1 ($skipped_reason)\"\n \t\t: true\n+\t\tfinalize_test_case_output skip \"$@\"\n \t\t;;\n \t*)\n \t\tfalse\n-- \ngitgitgadget\n"},{"id":"446779","messageId":"1a6bd1846bcb061d3dc70870139cb4bc076d2a25.1643050574.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"[PATCH 8/9] ci: use `--github-workflow-markup` in the GitHub workflow","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-01-24T18:56:13Z","receivedAt":"2022-01-24T19:02:12Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nThis makes the output easier to digest.\n\nNote: since workflow output currently cannot contain any nested groups\n(see https://github.com/actions/runner/issues/802 for details), we need\nto remove the explicit grouping that would span the entirety of each\nfailed test script.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/lib.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 4ed8f40ab02..72efdb556ed 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -176,7 +176,7 @@ then\n \t\t\ttest_name=\"${test_exit%.exit}\"\n \t\t\ttest_name=\"${test_name##*/}\"\n \t\t\tprintf \"\\\\e[33m\\\\e[1m=== Failed test: ${test_name} ===\\\\e[m\\\\n\"\n-\t\t\tgroup \"Failed test: $test_name\" cat \"t/test-results/$test_name.out\"\n+\t\t\tcat \"t/test-results/$test_name.markup\"\n \n \t\t\ttrash_dir=\"t/trash directory.$test_name\"\n \t\t\tcp \"t/test-results/$test_name.out\" t/failed-test-artifacts/\n@@ -188,7 +188,7 @@ then\n \tcache_dir=\"$HOME/none\"\n \n \texport GIT_PROVE_OPTS=\"--timer --jobs 10\"\n-\texport GIT_TEST_OPTS=\"--verbose-log -x\"\n+\texport GIT_TEST_OPTS=\"--verbose-log -x --github-workflow-markup\"\n \tMAKEFLAGS=\"$MAKEFLAGS --jobs=10\"\n \ttest windows != \"$CI_OS_NAME\" ||\n \tGIT_TEST_OPTS=\"--no-chain-lint --no-bin-wrappers $GIT_TEST_OPTS\"\n-- \ngitgitgadget\n\n"},{"id":"446780","messageId":"98b32630fcd76d591ce64f19314f3081134f541e.1643050574.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"[PATCH 7/9] ci: optionally mark up output in the GitHub workflow","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-01-24T18:56:12Z","receivedAt":"2022-01-24T19:02:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nA couple of commands exist to spruce up the output in GitHub workflows:\nhttps://docs.github.com/en/actions/learn-github-actions/workflow-commands-for-github-actions\n\nIn addition to the `::group::<label>`/`::endgroup::` commands (which we\nalready use to structure the output of the build step better), we also\nuse `::error::`/`::notice::` to draw the attention to test failures and\nto test cases that were expected to fail but didn't.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib-functions.sh              |  4 +--\n t/test-lib-github-workflow-markup.sh | 50 ++++++++++++++++++++++++++++\n t/test-lib.sh                        |  5 ++-\n 3 files changed, 56 insertions(+), 3 deletions(-)\n create mode 100644 t/test-lib-github-workflow-markup.sh\n\ndiff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\nindex c3d38aaccbd..b5fe5f66085 100644\n--- a/t/test-lib-functions.sh\n+++ b/t/test-lib-functions.sh\n@@ -719,7 +719,7 @@ test_verify_prereq () {\n }\n \n test_expect_failure () {\n-\ttest_start_\n+\ttest_start_ \"$@\"\n \ttest \"$#\" = 3 && { test_prereq=$1; shift; } || test_prereq=\n \ttest \"$#\" = 2 ||\n \tBUG \"not 2 or 3 parameters to test-expect-failure\"\n@@ -739,7 +739,7 @@ test_expect_failure () {\n }\n \n test_expect_success () {\n-\ttest_start_\n+\ttest_start_ \"$@\"\n \ttest \"$#\" = 3 && { test_prereq=$1; shift; } || test_prereq=\n \ttest \"$#\" = 2 ||\n \tBUG \"not 2 or 3 parameters to test-expect-success\"\ndiff --git a/t/test-lib-github-workflow-markup.sh b/t/test-lib-github-workflow-markup.sh\nnew file mode 100644\nindex 00000000000..d8dc969df4a\n--- /dev/null\n+++ b/t/test-lib-github-workflow-markup.sh\n@@ -0,0 +1,50 @@\n+# Library of functions to mark up test scripts' output suitable for\n+# pretty-printing it in GitHub workflows.\n+#\n+# Copyright (c) 2022 Johannes Schindelin\n+#\n+# This program is free software: you can redistribute it and/or modify\n+# it under the terms of the GNU General Public License as published by\n+# the Free Software Foundation, either version 2 of the License, or\n+# (at your option) any later version.\n+#\n+# This program is distributed in the hope that it will be useful,\n+# but WITHOUT ANY WARRANTY; without even the implied warranty of\n+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n+# GNU General Public License for more details.\n+#\n+# You should have received a copy of the GNU General Public License\n+# along with this program.  If not, see http://www.gnu.org/licenses/ .\n+#\n+# The idea is for `test-lib.sh` to source this file when run in GitHub\n+# workflows; these functions will then override (empty) functions\n+# that are are called at the appropriate times during the test runs.\n+\n+start_test_output () {\n+\ttest -n \"$GIT_TEST_TEE_OUTPUT_FILE\" ||\n+\tdie \"--github-workflow-markup requires --verbose-log\"\n+\tgithub_markup_output=\"${GIT_TEST_TEE_OUTPUT_FILE%.out}.markup\"\n+\t>$github_markup_output\n+\tGIT_TEST_TEE_OFFSET=0\n+}\n+\n+# No need to override start_test_case_output\n+\n+finalize_test_case_output () {\n+\ttest_case_result=$1\n+\tshift\n+\tcase \"$test_case_result\" in\n+\tfailure)\n+\t\techo >>$github_markup_output \"::error::failed: $this_test.$test_count $1\"\n+\t\t;;\n+\tfixed)\n+\t\techo >>$github_markup_output \"::notice::fixed: $this_test.$test_count $1\"\n+\t\t;;\n+\tesac\n+\techo >>$github_markup_output \"::group::$test_case_result: $this_test.$test_count $*\"\n+\ttest-tool >>$github_markup_output path-utils skip-n-bytes \\\n+\t\t\"$GIT_TEST_TEE_OUTPUT_FILE\" $GIT_TEST_TEE_OFFSET\n+\techo >>$github_markup_output \"::endgroup::\"\n+}\n+\n+# No need to override finalize_test_output\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex e13e1cb9124..076bee58c19 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -174,6 +174,9 @@ parse_option () {\n \t--write-junit-xml)\n \t\t. \"$TEST_DIRECTORY/test-lib-junit.sh\"\n \t\t;;\n+\t--github-workflow-markup)\n+\t\t. \"$TEST_DIRECTORY/test-lib-github-workflow-markup.sh\"\n+\t\t;;\n \t--stress)\n \t\tstress=t ;;\n \t--stress=*)\n@@ -1027,7 +1030,7 @@ test_start_ () {\n \ttest_count=$(($test_count+1))\n \tmaybe_setup_verbose\n \tmaybe_setup_valgrind\n-\tstart_test_case_output\n+\tstart_test_case_output \"$@\"\n }\n \n test_finish_ () {\n-- \ngitgitgadget\n\n"},{"id":"446821","messageId":"CAPig+cTk142o5xkN0jHB6y1h=4zYBwhpwdTxG0oO3Ox+xqdgdQ@mail.gmail.com","threadId":"57297","inReplyTo":"d2ff51bb5dacfe084166de106e9a864c902f0f36.1643050574.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 2/9] ci/run-build-and-tests: take a more high-level view","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2022-01-24T23:22:23Z","receivedAt":"2022-01-25T02:00:54Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Jan 24, 2022 at 3:02 PM Johannes Schindelin via GitGitGadget\n<gitgitgadget@gmail.com> wrote:\n> In the web UI of GitHub workflows, failed runs are presented with the\n> job step that failed auto-expanded. In the current setup, this is not\n> helpful at all because that shows only the output of `prove`, which says\n> which test failed, but not in what way.\n>\n> What would help understand the reader what went wrong is the verbose\n> test output of the failed test.\n>\n> The logs of the failed runs do contain that verbose test output, but it\n> is shown in the _next_ step (which is marked as succeeding, and is\n> therefore _not_ auto-expanded). Anyone not intimately familiar with this\n> would completely miss the verbose test output, being left mostly\n> puzzled with the test failures.\n>\n> We are about to show the failed test cases' output in the _same_ step,\n> so that the user has a much easier time to figure out what was going\n> wrong.\n>\n> But first, we must partially revert the change that tried to improve the\n> CI runs by combining the `Makefile` targets to build into a single\n> `make` invocation. That might have sounded like a good idea at the time,\n> but it does make it rather impossible for the CI script to determine\n> whether the _build_ failed, or the _tests_. If the tests were run at\n> all, that is.\n>\n> So let's go back to calling `make` for the build, and call `make test`\n> separately so that we can easily detect that _that_ invocation failed,\n> and react appropriately.\n>\n> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> ---\n> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\n> @@ -10,7 +10,7 @@ windows*) cmd //c mklink //j t\\\\.prove \"$(cygpath -aw \"$cache_dir/.prove\")\";;\n> -export MAKE_TARGETS=\"all test\"\n> +run_tests=t\n>\n>  case \"$jobname\" in\n>  linux-gcc)\n> @@ -41,14 +41,18 @@ pedantic)\n>         # Don't run the tests; we only care about whether Git can be\n>         # built.\n>         export DEVOPTS=pedantic\n> -       export MAKE_TARGETS=all\n> +       run_tests=\n>         ;;\n>  esac\n>\n>  # Any new \"test\" targets should not go after this \"make\", but should\n>  # adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n>  # start running tests.\n> -make $MAKE_TARGETS\n\nThe comment talking about MAKE_TARGETS seems out of date now that\nMAKE_TARGETS has been removed from this script.\n\n> +make\n> +if test -n \"$run_tests\"\n> +then\n> +       make test\n> +fi\n>  check_unignored_build_artifacts\n\nThis changes behavior, doesn't it? Wth the original \"make all test\",\nif the `all` target failed, then the `test` target would not be\ninvoked. However, with the revised code, `make test` is invoked even\nif `make all` fails. Is that behavior change significant? Do we care\nabout it?\n"},{"id":"446849","messageId":"nycvar.QRO.7.76.6.2201251527000.2121@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"CAPig+cTk142o5xkN0jHB6y1h=4zYBwhpwdTxG0oO3Ox+xqdgdQ@mail.gmail.com","subject":"Re: [PATCH 2/9] ci/run-build-and-tests: take a more high-level view","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-01-25T14:34:37Z","receivedAt":"2022-01-25T14:40:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Eric,\n\nOn Mon, 24 Jan 2022, Eric Sunshine wrote:\n\n> On Mon, Jan 24, 2022 at 3:02 PM Johannes Schindelin via GitGitGadget\n> <gitgitgadget@gmail.com> wrote:\n> > In the web UI of GitHub workflows, failed runs are presented with the\n> > job step that failed auto-expanded. In the current setup, this is not\n> > helpful at all because that shows only the output of `prove`, which says\n> > which test failed, but not in what way.\n> >\n> > What would help understand the reader what went wrong is the verbose\n> > test output of the failed test.\n> >\n> > The logs of the failed runs do contain that verbose test output, but it\n> > is shown in the _next_ step (which is marked as succeeding, and is\n> > therefore _not_ auto-expanded). Anyone not intimately familiar with this\n> > would completely miss the verbose test output, being left mostly\n> > puzzled with the test failures.\n> >\n> > We are about to show the failed test cases' output in the _same_ step,\n> > so that the user has a much easier time to figure out what was going\n> > wrong.\n> >\n> > But first, we must partially revert the change that tried to improve the\n> > CI runs by combining the `Makefile` targets to build into a single\n> > `make` invocation. That might have sounded like a good idea at the time,\n> > but it does make it rather impossible for the CI script to determine\n> > whether the _build_ failed, or the _tests_. If the tests were run at\n> > all, that is.\n> >\n> > So let's go back to calling `make` for the build, and call `make test`\n> > separately so that we can easily detect that _that_ invocation failed,\n> > and react appropriately.\n> >\n> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > ---\n> > diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\n> > @@ -10,7 +10,7 @@ windows*) cmd //c mklink //j t\\\\.prove \"$(cygpath -aw \"$cache_dir/.prove\")\";;\n> > -export MAKE_TARGETS=\"all test\"\n> > +run_tests=t\n> >\n> >  case \"$jobname\" in\n> >  linux-gcc)\n> > @@ -41,14 +41,18 @@ pedantic)\n> >         # Don't run the tests; we only care about whether Git can be\n> >         # built.\n> >         export DEVOPTS=pedantic\n> > -       export MAKE_TARGETS=all\n> > +       run_tests=\n> >         ;;\n> >  esac\n> >\n> >  # Any new \"test\" targets should not go after this \"make\", but should\n> >  # adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n> >  # start running tests.\n> > -make $MAKE_TARGETS\n>\n> The comment talking about MAKE_TARGETS seems out of date now that\n> MAKE_TARGETS has been removed from this script.\n\nGood catch!\n\n> > +make\n> > +if test -n \"$run_tests\"\n> > +then\n> > +       make test\n> > +fi\n> >  check_unignored_build_artifacts\n>\n> This changes behavior, doesn't it? Wth the original \"make all test\",\n> if the `all` target failed, then the `test` target would not be\n> invoked. However, with the revised code, `make test` is invoked even\n> if `make all` fails. Is that behavior change significant? Do we care\n> about it?\n\nThat is actually not the case. Compare to what 25715419bf4 (CI: don't run\n\"make test\" twice in one job, 2021-11-23) did: it removed code that _also_\ndid not specifically prevent `make test` from running when `make all`\nfailed.\n\nThe clue to the riddle is this line in `ci/lib.sh`:\n\n\tset -ex\n\nThe `-e` part lets the script fail whenever any command fails (unless it\nis part of an `if`/`while` condition, or properly chained with `||`).\n\nThis line is actually touched by the \"ci/run-build-and-tests: add some\nstructure to the GitHub workflow output\" patch in this patch series, which\nbreaks it apart into the `set -e` and the `set -x` part (so that the\nlatter can be called later in GitHub workflows, to unclutter the output a\nbit).\n\nCiao,\nDscho\n"},{"id":"446898","messageId":"220126.86sftbfjl4.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"98891b0d3f7927086350cc9523736ae2eb7c1ee2.1643050574.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 3/9] ci: make it easier to find failed tests' logs in the GitHub workflow","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-01-25T23:48:03Z","receivedAt":"2022-01-26T00:04:44Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Jan 24 2022, Johannes Schindelin via GitGitGadget wrote:\n\n> From: Johannes Schindelin <johannes.schindelin@gmx.de>\n>\n> You currently have to know a lot of implementation details when\n> investigating test failures in the CI runs. The first step is easy: the\n> failed job is marked quite clearly, but when opening it, the failed step\n> is expanded, which in our case is the one running\n> `ci/run-build-and-tests.sh`. This step, most notably, only offers a\n> high-level view of what went wrong: it prints the output of `prove`\n> which merely tells the reader which test script failed.\n>\n> The actually interesting part is in the detailed log of said failed\n> test script. But that log is shown in the CI run's step that runs\n> `ci/print-test-failures.sh`. And that step is _not_ expanded in the web\n> UI by default.\n>\n> Let's help the reader by showing the failed tests' detailed logs in the\n> step that is expanded automatically, i.e. directly after the test suite\n> failed.\n>\n> This also helps the situation where the _build_ failed and the\n> `print-test-failures` step was executed under the assumption that the\n> _test suite_ failed, and consequently failed to find any failed tests.\n>\n> An alternative way to implement this patch would be to source\n> `ci/print-test-failures.sh` in the `handle_test_failures` function to\n> show these logs. However, over the course of the next few commits, we\n> want to introduce some grouping which would be harder to achieve that\n> way (for example, we do want a leaner, and colored, preamble for each\n> failed test script, and it would be trickier to accommodate the lack of\n> nested groupings in GitHub workflows' output).\n\nIs it really better to have the first thing you see in a failing job be\nthis level of detail?\n\nTo take the \"before\" demo job from your CL, if you click on a failing\njob you'll currently end up with ~1600 lines of \"prove\" setup and\noutput, culminating in (the browser auto-scrolls to the end):\n\n    [...]\n    Test Summary Report\n    -------------------\n    t1092-sparse-checkout-compatibility.sh           (Wstat: 256 Tests: 53 Failed: 1)\n      Failed test:  49\n      Non-zero exit status: 1\n    t3701-add-interactive.sh                         (Wstat: 0 Tests: 71 Failed: 0)\n      TODO passed:   45, 47\n    Files=957, Tests=25489, 645 wallclock secs ( 5.74 usr  1.56 sys + 866.28 cusr 364.34 csys = 1237.92 CPU)\n    Result: FAIL\n\nIs it ideal? No. But I think that folding the ci/print-test-failures.sh\noutput into that step makes it much worse. Now I'll be sent to the very\nbottom of ~16000 lines (yes, that's an extra zero at the end) of output,\nending in:\n\n    [...]\n    + test_cmp expect sparse-checkout-out\n    + test 2 -ne 2\n    + GIT_ALLOC_LIMIT=0 eval diff -u \"$@\"\n    + diff -u expect sparse-checkout-out\n    + test_cmp full-checkout-err sparse-checkout-err\n    + test 2 -ne 2\n    + GIT_ALLOC_LIMIT=0 eval diff -u \"$@\"\n    + diff -u full-checkout-err sparse-checkout-err\n    + test_cmp full-checkout-err sparse-index-err\n    + test 2 -ne 2\n    + GIT_ALLOC_LIMIT=0 eval diff -u \"$@\"\n    + diff -u full-checkout-err sparse-index-err\n    \n    ok 53 - checkout behaves oddly with df-conflict-2\n    # failed 1 among 53 test(s)\n    1..53\n\nNow you'll need to scroll up or search just to see what test failed.\n\nUsually when these fail I might only look at the failing test name (at\nthat point already knowing why it failed). I think it's a feature that\nwe only expand the verbose output later.\n\nI realize that:\n\n1) This isn't the exact output you emit in the post-image here, since you're not\nactually using ci/print-test-failures.sh, but from eyeballing the script\nit seems to do basically the same thing, i.e. it'll emit the full *.out\nfile.\n\nB.t.w. why isn't this using ci/print-test-failures.sh. Your \"an\nalternative way\" paragraph doesn't really explain it. Sure, it'll be\nfurther tweaked later, but in the meantime do we have to re-invent\nci/print-test-failures.sh? Anyway...\n\n2) The end-state at the end of this series looks somewhat different, but I think\nthat end-state shares the UX problem noted above, and to some extent\nmakes it worse.\n\nThat one has 28 thousand lines of output!\n\nNow I know it's elided so you're only supposed to see a few screenfulls\nof it, but at least in my browser that end-state is *very slow*, much\nslower than the version that shows me the full ~16 thousand lines at\nonce.\n\nPresumably it's doing some very expensive JavaScript/CSS behind the\nscenes.\n\nI mean so slow that when I press page up and down I can see 3-8 lines of\nthat folded output appear at once, then the next 3-8 lines etc. The\ncurrent output meanwhile (and this more verbose one) is\nnear-instant. This is in Firefox 91.4, if it matters.\n"},{"id":"446901","messageId":"220126.86o83zfj5m.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"94dcbe1bc437dc9738cfc635e9085d743eb4ec98.1643050574.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 5/9] tests: refactor --write-junit-xml code","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-01-26T00:10:01Z","receivedAt":"2022-01-26T00:14:01Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Jan 24 2022, Johannes Schindelin via GitGitGadget wrote:\n\n> From: Johannes Schindelin <johannes.schindelin@gmx.de>\n>\n> The code writing JUnit XML is interspersed directly with all the code in\n> `t/test-lib.sh`, and it is therefore not only ill-separated, but\n> introducing yet another output format would make the situation even\n> worse.\n>\n> Let's introduce an abstraction layer by hiding the JUnit XML code behind\n> four new functions that are supposed to be called before and after each\n> test and test case.\n>\n> This is not just an academic exercise, refactoring for refactoring's\n> sake. We _actually_ want to introduce such a new output format, to\n> make it substantially easier to diagnose test failures in our GitHub\n> workflow, therefore we do need this refactoring.\n\nI'm a bit confused about the need to patch this JUnit code & to\ngeneralize test-lib.sh to emit things in three machine-readable formats\n(TAP, JUnit, and now this Markdown format).\n\nIn\nhttps://lore.kernel.org/git/nycvar.QRO.7.76.6.2112201834050.347@tvgsbejvaqbjf.bet/\nyou replied to my patch to remove this dead code with wanting to keep\nit, because:\n    \n    The reason is that there are still some things that Azure Pipelines can do\n    that GitHub workflows cannot, for example:\n    \n    - present the logs of failed tests in an intuitive manner,\n    \n    - re-run _only_ failed jobs.\n\nWhich is fair enough, but in this series we're further patching it, but\nit's still not used anywhere in-tree at the end of it, or am I missing\nsomething?\n\nThis series is seeking to address 1/2 of the points you mentioned, and\npresumably the latter is a question of us juggling around our GitHub CI\njob definitions.\n\nThen in 6/9 you note:\n\n    This seems not to faze Azure Pipelines' XML parser, but it still is\n    incorrect, so let's fix it.\n\nSo this is running on Azure somehow, but not via the previously in-tree\nazure-pipeline.yml removed in your 6081d3898fe (ci: retire the Azure\nPipelines definition, 2020-04-11)?\n"},{"id":"446904","messageId":"220126.86k0enfid9.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-01-26T00:25:54Z","receivedAt":"2022-01-26T00:31:03Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Jan 24 2022, Johannes Schindelin via GitGitGadget wrote:\n\n> Background\n> ==========\n>\n> Recent patches intended to help readers figure out CI failures much quicker\n> than before. Unfortunately, they haven't been entirely positive for me. For\n> example, they broke the branch protections in Microsoft's fork of Git, where\n> we require Pull Requests to pass a certain set of Checks (which are\n> identified by their names) and therefore caused follow-up work.\n\nThis seems to be a reference to my df7375d7728 (CI: use shorter names\nthat fit in UX tooltips, 2021-11-23) merged as part of ab/ci-updates,\nand I understand from this summary that you had some custom job\nsomewhere that scraped the job names which broke.\n\nThat's unfortunate, I do think being able to actually read the tooltips\nin the GitHub UI was a worthwhile trade-off in the end though.\n\nBut I'm entirely confused about what any of that has to do with this\nseries, which is about changing how the job output itself is presented\nand summarized, and not about the job names, and making them fit in\ntooltips.\n\nLater in the summary you note: \n\n> Using CI and in general making it easier for new contributors is an area I'm\n> passionate about, and one I'd like to see improved.\n> [...]\n> ⊗ linux-gcc (ubuntu-latest)\n>    failed: t9800.20 submit from detached head\n\nWhich has one of the new and shorter jobnames, but in a part of the UX\nwhere the length didn't matter, and I can't find a way where it does.\n"},{"id":"447099","messageId":"220127.86ilu5cdnf.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"CI \"grouping\" within jobs v.s. lighter split-out jobs (was: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-01-27T16:31:51Z","receivedAt":"2022-01-27T17:05:48Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\n[CC-ing some people who've been interested in CI architechture]\n\nOn Mon, Jan 24 2022, Johannes Schindelin via GitGitGadget wrote:\n\n> [...]\n> The current situation\n> =====================\n>\n> Let me walk you through the current experience when a PR build fails: I get\n> a notification mail that only says that a certain job failed. There's no\n> indication of which test failed (or was it the build?). I can click on a\n> link at it takes me to the workflow run. Once there, all it says is \"Process\n> completed with exit code 1\", or even \"code 2\". Sure, I can click on one of\n> the failed jobs. It even expands the failed step's log (collapsing the other\n> steps). And what do I see there?\n>\n> Let's look at an example of a failed linux-clang (ubuntu-latest) job\n> [https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true]:\n>\n> [...]\n> Test Summary Report\n> -------------------\n> t1092-sparse-checkout-compatibility.sh           (Wstat: 256 Tests: 53 Failed: 1)\n>   Failed test:  49\n>   Non-zero exit status: 1\n> t3701-add-interactive.sh                         (Wstat: 0 Tests: 71 Failed: 0)\n>   TODO passed:   45, 47\n> Files=957, Tests=25489, 645 wallclock secs ( 5.74 usr  1.56 sys + 866.28 cusr 364.34 csys = 1237.92 CPU)\n> Result: FAIL\n> make[1]: *** [Makefile:53: prove] Error 1\n> make[1]: Leaving directory '/home/runner/work/git/git/t'\n> make: *** [Makefile:3018: test] Error 2\n>\n\nFirstly I very much applaud any effort to move the CI UX forward. I know\nwe haven't seen eye-to-eye on some of the trade-offs there, but I think\nsomething like this series is a step in the right direction. I.e. trying\nharder to summarize the output for the user, and making use of some CI\nplatform-specific features.\n\nI sent a reply in this thread purely on some implementation concerns\nrelated to that in\nhttps://lore.kernel.org/git/220126.86sftbfjl4.gmgdl@evledraar.gmail.com/,\nbut let's leave that aside for now...\n\n> [...]\n> So I had a look at what standards exist e.g. when testing PowerShell\n> modules, in the way of marking up their test output in GitHub workflows, and\n> I was not disappointed: GitHub workflows support \"grouping\" of output lines,\n> i.e. marking sections of the output as a group that is then collapsed by\n> default and can be expanded. And it is this feature I decided to use in this\n> patch series, along with GitHub workflows' commands to display errors or\n> notices that are also shown on the summary page of the workflow run. Now, in\n> addition to \"Process completed with exit code\" on the summary page, we also\n> read something like:\n>\n> ⊗ linux-gcc (ubuntu-latest)\n>    failed: t9800.20 submit from detached head\n>\n> Even better, this message is a link, and following that, the reader is\n> presented with something like this\n> [https://github.com/dscho/git/runs/4840190622?check_suite_focus=true]:\n\nThis series is doing several different things, at least:\n\n 1) \"Grouping\" the ci/ output, i.e. \"make\" from \"make test\"\n 2) Doing likewise for t/test-lib.sh\n 3) In doing that for t/test-lib.sh, also \"signalling\" the GitHub CI,\n    to e.g. get the \"submit from detached head\" output you quote just\n    a few lines above\n\nI'd like to focus on just #1 here.\n\nWhere I was going with that in my last CI series was to make a start at\neventually being able to run simply \"make\" at the top-level\n\"step\". I.e. to have a recipe that looks like:\n\n    - run: make\n    - run: make test\n\nI feel strongly that that's where we should be heading, and the #1 part\nof this series is basically trying to emulate what you'd get for free if\nwe simply did that.\n\nI.e. if you run single commands at the \"step\" level (in GitHub CI\nnomenclature) you'll get what you're doing with groupings in this series\nfor free, and without any special code in ci/*, better yet if you then\ndo want grouping *within* that step you're free to do so without having\nclobbered your one-level of grouping already on distinguishing \"make\"\nfrom \"make test\".\n\nIOW our CI now looks like this (pseudocode):\n\n     - job:\n       - step1:\n         - use ci/lib.sh to set env vars\n         - run a script like ci/run-build-and-tests.sh\n       - step2:\n         - use ci/lib.sh to set env vars\n         - run a script like print-test-failures.sh\n\nBut should instead look like:\n\n     - job:\n       - step1:\n         - set variables in $GITHUB_ENV using ci/lib.sh\n       - step2:\n         - make\n       - step3:\n         - make test\n       - step4:\n         - run a script like print-test-failures.sh\n\nWell, we can quibble about \"step4\", but again, let's focus on #1 here,\nthat's more #2-#3 territory.\n\nI had some WIP code to do that which I polished up, here's how e.g. a\nbuild failure looks like in your implementation (again, just focusing on\nhow \"make\" and \"make test\" is divided out, not the rest):\n\n    https://github.com/dscho/git/runs/4840190622?check_suite_focus=true#step:4:62\n\nI.e. you've made \"build\" an expandable group at the same level as a\nsingle failed test, and still all under the opaque\nci/run-build-and-test.sh script.\n\nAnd here's mine. This is using a semi-recent version of my patches that\nhappened to have a failure, not quite what I've got now, but close\nenough for this E-Mail:\n\n    https://github.com/avar/git/runs/4956260395?check_suite_focus=true#step:7:1\n\nNow, notice two things, one we've made \"make\" and \"make test\" top-level\nsteps, but more importantly if you expand that \"make test\" step on yours\nyou'll get the full \"make test\" output,\n\nAnd two it's got something you don't have at all, which is that we're\nnow making use of the GitHub CI feature of having pre-declared an\nenvironment for \"make test\", which the CI knows about (you need to click\nto expand it):\n\n    https://github.com/avar/git/runs/4956260395?check_suite_focus=true#step:7:4\n\nRight now that's something we hardly make use of at all, but with my\nchanges the environment is the *only* special sauce we specify before\nthe step, i.e. GIT_PROVE_OPTS=.. DEFAULT_TEST_TARGET=... etc.\n\nI think I've run out of my ML quota for now, but here's the branch that implements it:\n\n    https://github.com/git/git/compare/master...avar:avar/ci-unroll-make-commands-to-ci-recipe\n\nThat's \"282 additions and 493 deletions.\", much of what was required to\ndo this was to eject the remaining support for the dead Travis and Azure\nCI's that we don't run, i.e. to entirely remove any sort of state\nmanagement or job control from ci/lib.sh, and have it *only* be tasked\nwith setting variables for subsequent steps to use.\n\nThat makes it much simpler, my end-state of it is ~170 lines v.s. your\n~270 (but to be fair some of that's deleted Travis code):\n\n    https://github.com/avar/git/blob/avar/ci-unroll-make-commands-to-ci-recipe/ci/lib.sh\n    https://github.com/gitgitgadget/git/blob/pr-1117/dscho/use-grouping-in-ci-v1/ci/lib.sh\n\nAnd much of the rest is just gone, e.g. ci/run-build-and-tests.sh isn't\nthere anymore, instead you simply run \"make\" or \"make test\" (or the\nequivalent on Windows, which also works):\n\n    https://github.com/avar/git/tree/avar/ci-unroll-make-commands-to-ci-recipe/ci\n    https://github.com/gitgitgadget/git/tree/pr-1117/dscho/use-grouping-in-ci-v1/ci\n\nAnyway, I hope we can find some sort of joint way forward with this,\nbecause I think your #1 at least is going in the opposite direction we\nshould be going to achieve much the same ends you'd like to achieve.\n\nWe can really just do this in a much simpler way once we stop treating\nci/lib.sh and friends as monolithic ball of mud entry points.\n\nBut I'd really like us not to go in this direction of using markup to\n\"sub-divide\" the \"steps\" within a given job, when we can relatively\neasily just ... divide the steps.\n\nAs shown above that UI plays much more naturally into the CI's native\nfeatures & how it likes to arrange & present things.\n\nAnd again, all of this is *only* discussing the \"step #1\" noted\nabove. Using \"grouping\" for presenting the test failures themselves or\nsending summaries to the CI \"Summary\" is a different matter.\n\nThanks!\n\n\n\n"},{"id":"448871","messageId":"nycvar.QRO.7.76.6.2202200043590.26495@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-02-19T23:46:24Z","receivedAt":"2022-02-19T23:46:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nI notice that you did not take this into `seen` yet. I find that a little\nsad because it would potentially have helped others to figure out the\nfailure in the latest `seen`:\nhttps://github.com/git/git/runs/5255378056?check_suite_focus=true#step:5:162\n\nEssentially, a recent patch introduces hard-coded SHA-1 hashes in t3007.3.\n\nCiao,\nDscho\n\n\nOn Mon, 24 Jan 2022, Johannes Schindelin via GitGitGadget wrote:\n\n>\n> Background\n> ==========\n>\n> Recent patches intended to help readers figure out CI failures much quicker\n> than before. Unfortunately, they haven't been entirely positive for me. For\n> example, they broke the branch protections in Microsoft's fork of Git, where\n> we require Pull Requests to pass a certain set of Checks (which are\n> identified by their names) and therefore caused follow-up work.\n>\n> Using CI and in general making it easier for new contributors is an area I'm\n> passionate about, and one I'd like to see improved.\n>\n>\n> The current situation\n> =====================\n>\n> Let me walk you through the current experience when a PR build fails: I get\n> a notification mail that only says that a certain job failed. There's no\n> indication of which test failed (or was it the build?). I can click on a\n> link at it takes me to the workflow run. Once there, all it says is \"Process\n> completed with exit code 1\", or even \"code 2\". Sure, I can click on one of\n> the failed jobs. It even expands the failed step's log (collapsing the other\n> steps). And what do I see there?\n>\n> Let's look at an example of a failed linux-clang (ubuntu-latest) job\n> [https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true]:\n>\n> [...]\n> Test Summary Report\n> -------------------\n> t1092-sparse-checkout-compatibility.sh           (Wstat: 256 Tests: 53 Failed: 1)\n>   Failed test:  49\n>   Non-zero exit status: 1\n> t3701-add-interactive.sh                         (Wstat: 0 Tests: 71 Failed: 0)\n>   TODO passed:   45, 47\n> Files=957, Tests=25489, 645 wallclock secs ( 5.74 usr  1.56 sys + 866.28 cusr 364.34 csys = 1237.92 CPU)\n> Result: FAIL\n> make[1]: *** [Makefile:53: prove] Error 1\n> make[1]: Leaving directory '/home/runner/work/git/git/t'\n> make: *** [Makefile:3018: test] Error 2\n>\n>\n> That's it. I count myself lucky not to be a new contributor being faced with\n> something like this.\n>\n> Now, since I am active in the Git project for a couple of days or so, I can\n> make sense of the \"TODO passed\" label and know that for the purpose of\n> fixing the build failures, I need to ignore this, and that I need to focus\n> on the \"Failed test\" part instead.\n>\n> I also know that I do not have to get myself an ubuntu-latest box just to\n> reproduce the error, I do not even have to check out the code and run it\n> just to learn what that \"49\" means.\n>\n> I know, and I do not expect any new contributor, not even most seasoned\n> contributors to know, that I have to patiently collapse the \"Run\n> ci/run-build-and-tests.sh\" job's log, and instead expand the \"Run\n> ci/print-test-failures.sh\" job log (which did not fail and hence does not\n> draw any attention to it).\n>\n> I know, and again: I do not expect many others to know this, that I then\n> have to click into the \"Search logs\" box (not the regular web browser's\n> search via Ctrl+F!) and type in \"not ok\" to find the log of the failed test\n> case (and this might still be a \"known broken\" one that is marked via\n> test_expect_failure and once again needs to be ignored).\n>\n> To be excessively clear: This is not a great experience!\n>\n>\n> Improved output\n> ===============\n>\n> Our previous Azure Pipelines-based CI builds had a much nicer UI, one that\n> even showed flaky tests, and trends e.g. how long the test cases ran. When I\n> ported Git's CI over to GitHub workflows (to make CI more accessible to new\n> contributors), I knew fully well that we would leave this very nice UI\n> behind, and I had hoped that we would get something similar back via new,\n> community-contributed GitHub Actions that can be used in GitHub workflows.\n> However, most likely because we use a home-grown test framework implemented\n> in opinionated POSIX shells scripts, that did not happen.\n>\n> So I had a look at what standards exist e.g. when testing PowerShell\n> modules, in the way of marking up their test output in GitHub workflows, and\n> I was not disappointed: GitHub workflows support \"grouping\" of output lines,\n> i.e. marking sections of the output as a group that is then collapsed by\n> default and can be expanded. And it is this feature I decided to use in this\n> patch series, along with GitHub workflows' commands to display errors or\n> notices that are also shown on the summary page of the workflow run. Now, in\n> addition to \"Process completed with exit code\" on the summary page, we also\n> read something like:\n>\n> ⊗ linux-gcc (ubuntu-latest)\n>    failed: t9800.20 submit from detached head\n>\n>\n> Even better, this message is a link, and following that, the reader is\n> presented with something like this\n> [https://github.com/dscho/git/runs/4840190622?check_suite_focus=true]:\n>\n> ⏵ Run ci/run-build-and-tests.sh\n> ⏵ CI setup\n>   + ln -s /home/runner/none/.prove t/.prove\n>   + run_tests=t\n>   + export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n>   + group Build make\n>   + set +x\n> ⏵ Build\n> ⏵ Run tests\n>   === Failed test: t9800-git-p4-basic ===\n> ⏵ ok: t9800.1 start p4d\n> ⏵ ok: t9800.2 add p4 files\n> ⏵ ok: t9800.3 basic git p4 clone\n> ⏵ ok: t9800.4 depot typo error\n> ⏵ ok: t9800.5 git p4 clone @all\n> ⏵ ok: t9800.6 git p4 sync uninitialized repo\n> ⏵ ok: t9800.7 git p4 sync new branch\n> ⏵ ok: t9800.8 clone two dirs\n> ⏵ ok: t9800.9 clone two dirs, @all\n> ⏵ ok: t9800.10 clone two dirs, @all, conflicting files\n> ⏵ ok: t9800.11 clone two dirs, each edited by submit, single git commit\n> ⏵ ok: t9800.12 clone using non-numeric revision ranges\n> ⏵ ok: t9800.13 clone with date range, excluding some changes\n> ⏵ ok: t9800.14 exit when p4 fails to produce marshaled output\n> ⏵ ok: t9800.15 exit gracefully for p4 server errors\n> ⏵ ok: t9800.16 clone --bare should make a bare repository\n> ⏵ ok: t9800.17 initial import time from top change time\n> ⏵ ok: t9800.18 unresolvable host in P4PORT should display error\n> ⏵ ok: t9800.19 run hook p4-pre-submit before submit\n>   Error: failed: t9800.20 submit from detached head\n> ⏵ failure: t9800.20 submit from detached head\n>   Error: failed: t9800.21 submit from worktree\n> ⏵ failure: t9800.21 submit from worktree\n>   === Failed test: t9801-git-p4-branch ===\n>   [...]\n>\n>\n> The \"Failed test:\" lines are colored in yellow to give a better visual clue\n> about the logs' structure, the \"Error:\" label is colored in red to draw the\n> attention to the important part of the log, and the \"⏵\" characters indicate\n> that part of the log is collapsed and can be expanded by clicking on it.\n>\n> To drill down, the reader merely needs to expand the (failed) test case's\n> log by clicking on it, and then study the log. If needed (e.g. when the test\n> case relies on side effects from previous test cases), the logs of preceding\n> test cases can be expanded as well. In this example, when expanding\n> t9800.20, it looks like this (for ease of reading, I cut a few chunks of\n> lines, indicated by \"[...]\"):\n>\n> [...]\n> ⏵ ok: t9800.19 run hook p4-pre-submit before submit\n>   Error: failed: t9800.20 submit from detached head\n> ⏷ failure: t9800.20 submit from detached head\n>       test_when_finished cleanup_git &&\n>       git p4 clone --dest=\"$git\" //depot &&\n>         (\n>           cd \"$git\" &&\n>           git checkout p4/master &&\n>           >detached_head_test &&\n>           git add detached_head_test &&\n>           git commit -m \"add detached_head\" &&\n>           git config git-p4.skipSubmitEdit true &&\n>           git p4 submit &&\n>             git p4 rebase &&\n>             git log p4/master | grep detached_head\n>         )\n>     [...]\n>     Depot paths: //depot/\n>     Import destination: refs/remotes/p4/master\n>\n>     Importing revision 9 (100%)Perforce db files in '.' will be created if missing...\n>     Perforce db files in '.' will be created if missing...\n>\n>     Traceback (most recent call last):\n>       File \"/home/runner/work/git/git/git-p4\", line 4455, in <module>\n>         main()\n>       File \"/home/runner/work/git/git/git-p4\", line 4449, in main\n>         if not cmd.run(args):\n>       File \"/home/runner/work/git/git/git-p4\", line 2590, in run\n>         rebase.rebase()\n>       File \"/home/runner/work/git/git/git-p4\", line 4121, in rebase\n>         if len(read_pipe(\"git diff-index HEAD --\")) > 0:\n>       File \"/home/runner/work/git/git/git-p4\", line 297, in read_pipe\n>         retcode, out, err = read_pipe_full(c, *k, **kw)\n>       File \"/home/runner/work/git/git/git-p4\", line 284, in read_pipe_full\n>         p = subprocess.Popen(\n>       File \"/usr/lib/python3.8/subprocess.py\", line 858, in __init__\n>         self._execute_child(args, executable, preexec_fn, close_fds,\n>       File \"/usr/lib/python3.8/subprocess.py\", line 1704, in _execute_child\n>         raise child_exception_type(errno_num, err_msg, err_filename)\n>     FileNotFoundError: [Errno 2] No such file or directory: 'git diff-index HEAD --'\n>     error: last command exited with $?=1\n>     + cleanup_git\n>     + retry_until_success rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + nr_tries_left=60\n>     + rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + test_path_is_missing /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + test 1 -ne 1\n>     + test -e /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + retry_until_success mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + nr_tries_left=60\n>     + mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + exit 1\n>     + eval_ret=1\n>     + :\n>     not ok 20 - submit from detached head\n>     #\n>     #        test_when_finished cleanup_git &&\n>     #        git p4 clone --dest=\"$git\" //depot &&\n>     #        (\n>     #            cd \"$git\" &&\n>     #            git checkout p4/master &&\n>     #            >detached_head_test &&\n>     #            git add detached_head_test &&\n>     #            git commit -m \"add detached_head\" &&\n>     #            git config git-p4.skipSubmitEdit true &&\n>     #            git p4 submit &&\n>     #            git p4 rebase &&\n>     #            git log p4/master | grep detached_head\n>     #        )\n>     #\n>   Error: failed: t9800.21 submit from worktree\n>   [...]\n>\n>\n> Is this the best UI we can have for test failures in CI runs? I hope we can\n> do better. Having said that, this patch series presents a pretty good start,\n> and offers a basis for future improvements.\n>\n> Johannes Schindelin (9):\n>   ci: fix code style\n>   ci/run-build-and-tests: take a more high-level view\n>   ci: make it easier to find failed tests' logs in the GitHub workflow\n>   ci/run-build-and-tests: add some structure to the GitHub workflow\n>     output\n>   tests: refactor --write-junit-xml code\n>   test(junit): avoid line feeds in XML attributes\n>   ci: optionally mark up output in the GitHub workflow\n>   ci: use `--github-workflow-markup` in the GitHub workflow\n>   ci: call `finalize_test_case_output` a little later\n>\n>  .github/workflows/main.yml           |  12 ---\n>  ci/lib.sh                            |  81 ++++++++++++++--\n>  ci/run-build-and-tests.sh            |  11 ++-\n>  ci/run-test-slice.sh                 |   5 +-\n>  t/test-lib-functions.sh              |   4 +-\n>  t/test-lib-github-workflow-markup.sh |  50 ++++++++++\n>  t/test-lib-junit.sh                  | 132 +++++++++++++++++++++++++++\n>  t/test-lib.sh                        | 128 ++++----------------------\n>  8 files changed, 287 insertions(+), 136 deletions(-)\n>  create mode 100644 t/test-lib-github-workflow-markup.sh\n>  create mode 100644 t/test-lib-junit.sh\n>\n>\n> base-commit: af4e5f569bc89f356eb34a9373d7f82aca6faa8a\n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1117%2Fdscho%2Fuse-grouping-in-ci-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1117/dscho/use-grouping-in-ci-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/1117\n> --\n> gitgitgadget\n>\n>\n"},{"id":"448877","messageId":"xmqqtucuw93i.fsf@gitster.g","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2202200043590.26495@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-02-20T02:44:01Z","receivedAt":"2022-02-20T02:44:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> I notice that you did not take this into `seen` yet. I find that a little\n> sad because it would potentially have helped others to figure out the\n> failure in the latest `seen`:\n> https://github.com/git/git/runs/5255378056?check_suite_focus=true#step:5:162\n>\n> Essentially, a recent patch introduces hard-coded SHA-1 hashes in t3007.3.\n\nI saw the thread, I saw a few patches were commented on, and a few\nwere left unanswered, but one was replied by the original submitter\nwith a \"Good catch!\", making me expect the topic to be discussed or\nrerolled to become ready relatively soon.\n\nBut nothing happened, so I even forgot to take a look myself by\npicking it up in 'seen'.  It does sound sad that the topic was left\nhanging there for 3 weeks or so in that state without any reroll or\nresponse.\n\n"},{"id":"448899","messageId":"220220.86bkz1d7hm.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2202200043590.26495@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-02-20T12:47:57Z","receivedAt":"2022-02-20T12:53:49Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Feb 20 2022, Johannes Schindelin wrote:\n\n> Hi Junio,\n>\n> I notice that you did not take this into `seen` yet. I find that a little\n> sad because it would potentially have helped others to figure out the\n> failure in the latest `seen`:\n> https://github.com/git/git/runs/5255378056?check_suite_focus=true#step:5:162\n>\n> Essentially, a recent patch introduces hard-coded SHA-1 hashes in t3007.3.\n\nI left some feedback on your submission ~3 weeks ago that you haven't\nresponded to:\nhttps://lore.kernel.org/git/220127.86ilu5cdnf.gmgdl@evledraar.gmail.com/\n\nI think you should really reply to that before this moves forward,\ni.e. it's not trivial concerns. I think to get from our current \"X\" to\nyour aims of \"Y\" your way of doing that (for part of this series) is\nreally an overly complex way of getting there that we can do much\nsimpler, and the simpler way integrates much better with the GitHub CI\nUI.\n\nThe feedback I left is on the part of this that's not directly relevant\nto what you're pointing out here (which is the grouping of the per-test\nfailure output), but if your series is picked-up as-is we'd need to undo\nrather big parts of it to get to what I consider a better state for the\n\"grouping\" of the \"make\" v.s. \"make test\" etc. output.\n\nI can just submit my version of that & we can hash out what direction\nmakes sense there, how does that sound? I've been running with it for\nabout a month, and really think that part of the failure output is much\nbetter.\n\nHere's an example of that part:\nhttps://github.com/avar/git/runs/5259000590?check_suite_focus=true\n\nI.e. note how we'll now just have a \"make\" and \"make test\" step, and we\nfailed there on the \"make\".\n\nSo we'd get to the point of simply invoking those build steps as 1=1\nmapped CI steps, as opposed to \"improving\" ci/run-build-and-tests.sh to\nemulate that (I've just git rm'd it in my version).\n\n>\n> On Mon, 24 Jan 2022, Johannes Schindelin via GitGitGadget wrote:\n>\n>>\n>> Background\n>> ==========\n>>\n>> Recent patches intended to help readers figure out CI failures much quicker\n>> than before. Unfortunately, they haven't been entirely positive for me. For\n>> example, they broke the branch protections in Microsoft's fork of Git, where\n>> we require Pull Requests to pass a certain set of Checks (which are\n>> identified by their names) and therefore caused follow-up work.\n>>\n>> Using CI and in general making it easier for new contributors is an area I'm\n>> passionate about, and one I'd like to see improved.\n>>\n>>\n>> The current situation\n>> =====================\n>>\n>> Let me walk you through the current experience when a PR build fails: I get\n>> a notification mail that only says that a certain job failed. There's no\n>> indication of which test failed (or was it the build?). I can click on a\n>> link at it takes me to the workflow run. Once there, all it says is \"Process\n>> completed with exit code 1\", or even \"code 2\". Sure, I can click on one of\n>> the failed jobs. It even expands the failed step's log (collapsing the other\n>> steps). And what do I see there?\n>>\n>> Let's look at an example of a failed linux-clang (ubuntu-latest) job\n>> [https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true]:\n>>\n>> [...]\n>> Test Summary Report\n>> -------------------\n>> t1092-sparse-checkout-compatibility.sh           (Wstat: 256 Tests: 53 Failed: 1)\n>>   Failed test:  49\n>>   Non-zero exit status: 1\n>> t3701-add-interactive.sh                         (Wstat: 0 Tests: 71 Failed: 0)\n>>   TODO passed:   45, 47\n>> Files=957, Tests=25489, 645 wallclock secs ( 5.74 usr  1.56 sys + 866.28 cusr 364.34 csys = 1237.92 CPU)\n>> Result: FAIL\n>> make[1]: *** [Makefile:53: prove] Error 1\n>> make[1]: Leaving directory '/home/runner/work/git/git/t'\n>> make: *** [Makefile:3018: test] Error 2\n>>\n>>\n>> That's it. I count myself lucky not to be a new contributor being faced with\n>> something like this.\n>>\n>> Now, since I am active in the Git project for a couple of days or so, I can\n>> make sense of the \"TODO passed\" label and know that for the purpose of\n>> fixing the build failures, I need to ignore this, and that I need to focus\n>> on the \"Failed test\" part instead.\n>>\n>> I also know that I do not have to get myself an ubuntu-latest box just to\n>> reproduce the error, I do not even have to check out the code and run it\n>> just to learn what that \"49\" means.\n>>\n>> I know, and I do not expect any new contributor, not even most seasoned\n>> contributors to know, that I have to patiently collapse the \"Run\n>> ci/run-build-and-tests.sh\" job's log, and instead expand the \"Run\n>> ci/print-test-failures.sh\" job log (which did not fail and hence does not\n>> draw any attention to it).\n>>\n>> I know, and again: I do not expect many others to know this, that I then\n>> have to click into the \"Search logs\" box (not the regular web browser's\n>> search via Ctrl+F!) and type in \"not ok\" to find the log of the failed test\n>> case (and this might still be a \"known broken\" one that is marked via\n>> test_expect_failure and once again needs to be ignored).\n>>\n>> To be excessively clear: This is not a great experience!\n>>\n>>\n>> Improved output\n>> ===============\n>>\n>> Our previous Azure Pipelines-based CI builds had a much nicer UI, one that\n>> even showed flaky tests, and trends e.g. how long the test cases ran. When I\n>> ported Git's CI over to GitHub workflows (to make CI more accessible to new\n>> contributors), I knew fully well that we would leave this very nice UI\n>> behind, and I had hoped that we would get something similar back via new,\n>> community-contributed GitHub Actions that can be used in GitHub workflows.\n>> However, most likely because we use a home-grown test framework implemented\n>> in opinionated POSIX shells scripts, that did not happen.\n>>\n>> So I had a look at what standards exist e.g. when testing PowerShell\n>> modules, in the way of marking up their test output in GitHub workflows, and\n>> I was not disappointed: GitHub workflows support \"grouping\" of output lines,\n>> i.e. marking sections of the output as a group that is then collapsed by\n>> default and can be expanded. And it is this feature I decided to use in this\n>> patch series, along with GitHub workflows' commands to display errors or\n>> notices that are also shown on the summary page of the workflow run. Now, in\n>> addition to \"Process completed with exit code\" on the summary page, we also\n>> read something like:\n>>\n>> ⊗ linux-gcc (ubuntu-latest)\n>>    failed: t9800.20 submit from detached head\n>>\n>>\n>> Even better, this message is a link, and following that, the reader is\n>> presented with something like this\n>> [https://github.com/dscho/git/runs/4840190622?check_suite_focus=true]:\n>>\n>> ⏵ Run ci/run-build-and-tests.sh\n>> ⏵ CI setup\n>>   + ln -s /home/runner/none/.prove t/.prove\n>>   + run_tests=t\n>>   + export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n>>   + group Build make\n>>   + set +x\n>> ⏵ Build\n>> ⏵ Run tests\n>>   === Failed test: t9800-git-p4-basic ===\n>> ⏵ ok: t9800.1 start p4d\n>> ⏵ ok: t9800.2 add p4 files\n>> ⏵ ok: t9800.3 basic git p4 clone\n>> ⏵ ok: t9800.4 depot typo error\n>> ⏵ ok: t9800.5 git p4 clone @all\n>> ⏵ ok: t9800.6 git p4 sync uninitialized repo\n>> ⏵ ok: t9800.7 git p4 sync new branch\n>> ⏵ ok: t9800.8 clone two dirs\n>> ⏵ ok: t9800.9 clone two dirs, @all\n>> ⏵ ok: t9800.10 clone two dirs, @all, conflicting files\n>> ⏵ ok: t9800.11 clone two dirs, each edited by submit, single git commit\n>> ⏵ ok: t9800.12 clone using non-numeric revision ranges\n>> ⏵ ok: t9800.13 clone with date range, excluding some changes\n>> ⏵ ok: t9800.14 exit when p4 fails to produce marshaled output\n>> ⏵ ok: t9800.15 exit gracefully for p4 server errors\n>> ⏵ ok: t9800.16 clone --bare should make a bare repository\n>> ⏵ ok: t9800.17 initial import time from top change time\n>> ⏵ ok: t9800.18 unresolvable host in P4PORT should display error\n>> ⏵ ok: t9800.19 run hook p4-pre-submit before submit\n>>   Error: failed: t9800.20 submit from detached head\n>> ⏵ failure: t9800.20 submit from detached head\n>>   Error: failed: t9800.21 submit from worktree\n>> ⏵ failure: t9800.21 submit from worktree\n>>   === Failed test: t9801-git-p4-branch ===\n>>   [...]\n>>\n>>\n>> The \"Failed test:\" lines are colored in yellow to give a better visual clue\n>> about the logs' structure, the \"Error:\" label is colored in red to draw the\n>> attention to the important part of the log, and the \"⏵\" characters indicate\n>> that part of the log is collapsed and can be expanded by clicking on it.\n>>\n>> To drill down, the reader merely needs to expand the (failed) test case's\n>> log by clicking on it, and then study the log. If needed (e.g. when the test\n>> case relies on side effects from previous test cases), the logs of preceding\n>> test cases can be expanded as well. In this example, when expanding\n>> t9800.20, it looks like this (for ease of reading, I cut a few chunks of\n>> lines, indicated by \"[...]\"):\n>>\n>> [...]\n>> ⏵ ok: t9800.19 run hook p4-pre-submit before submit\n>>   Error: failed: t9800.20 submit from detached head\n>> ⏷ failure: t9800.20 submit from detached head\n>>       test_when_finished cleanup_git &&\n>>       git p4 clone --dest=\"$git\" //depot &&\n>>         (\n>>           cd \"$git\" &&\n>>           git checkout p4/master &&\n>>           >detached_head_test &&\n>>           git add detached_head_test &&\n>>           git commit -m \"add detached_head\" &&\n>>           git config git-p4.skipSubmitEdit true &&\n>>           git p4 submit &&\n>>             git p4 rebase &&\n>>             git log p4/master | grep detached_head\n>>         )\n>>     [...]\n>>     Depot paths: //depot/\n>>     Import destination: refs/remotes/p4/master\n>>\n>>     Importing revision 9 (100%)Perforce db files in '.' will be created if missing...\n>>     Perforce db files in '.' will be created if missing...\n>>\n>>     Traceback (most recent call last):\n>>       File \"/home/runner/work/git/git/git-p4\", line 4455, in <module>\n>>         main()\n>>       File \"/home/runner/work/git/git/git-p4\", line 4449, in main\n>>         if not cmd.run(args):\n>>       File \"/home/runner/work/git/git/git-p4\", line 2590, in run\n>>         rebase.rebase()\n>>       File \"/home/runner/work/git/git/git-p4\", line 4121, in rebase\n>>         if len(read_pipe(\"git diff-index HEAD --\")) > 0:\n>>       File \"/home/runner/work/git/git/git-p4\", line 297, in read_pipe\n>>         retcode, out, err = read_pipe_full(c, *k, **kw)\n>>       File \"/home/runner/work/git/git/git-p4\", line 284, in read_pipe_full\n>>         p = subprocess.Popen(\n>>       File \"/usr/lib/python3.8/subprocess.py\", line 858, in __init__\n>>         self._execute_child(args, executable, preexec_fn, close_fds,\n>>       File \"/usr/lib/python3.8/subprocess.py\", line 1704, in _execute_child\n>>         raise child_exception_type(errno_num, err_msg, err_filename)\n>>     FileNotFoundError: [Errno 2] No such file or directory: 'git diff-index HEAD --'\n>>     error: last command exited with $?=1\n>>     + cleanup_git\n>>     + retry_until_success rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>>     + nr_tries_left=60\n>>     + rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>>     + test_path_is_missing /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>>     + test 1 -ne 1\n>>     + test -e /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>>     + retry_until_success mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>>     + nr_tries_left=60\n>>     + mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>>     + exit 1\n>>     + eval_ret=1\n>>     + :\n>>     not ok 20 - submit from detached head\n>>     #\n>>     #        test_when_finished cleanup_git &&\n>>     #        git p4 clone --dest=\"$git\" //depot &&\n>>     #        (\n>>     #            cd \"$git\" &&\n>>     #            git checkout p4/master &&\n>>     #            >detached_head_test &&\n>>     #            git add detached_head_test &&\n>>     #            git commit -m \"add detached_head\" &&\n>>     #            git config git-p4.skipSubmitEdit true &&\n>>     #            git p4 submit &&\n>>     #            git p4 rebase &&\n>>     #            git log p4/master | grep detached_head\n>>     #        )\n>>     #\n>>   Error: failed: t9800.21 submit from worktree\n>>   [...]\n>>\n>>\n>> Is this the best UI we can have for test failures in CI runs? I hope we can\n>> do better. Having said that, this patch series presents a pretty good start,\n>> and offers a basis for future improvements.\n>>\n>> Johannes Schindelin (9):\n>>   ci: fix code style\n>>   ci/run-build-and-tests: take a more high-level view\n>>   ci: make it easier to find failed tests' logs in the GitHub workflow\n>>   ci/run-build-and-tests: add some structure to the GitHub workflow\n>>     output\n>>   tests: refactor --write-junit-xml code\n>>   test(junit): avoid line feeds in XML attributes\n>>   ci: optionally mark up output in the GitHub workflow\n>>   ci: use `--github-workflow-markup` in the GitHub workflow\n>>   ci: call `finalize_test_case_output` a little later\n>>\n>>  .github/workflows/main.yml           |  12 ---\n>>  ci/lib.sh                            |  81 ++++++++++++++--\n>>  ci/run-build-and-tests.sh            |  11 ++-\n>>  ci/run-test-slice.sh                 |   5 +-\n>>  t/test-lib-functions.sh              |   4 +-\n>>  t/test-lib-github-workflow-markup.sh |  50 ++++++++++\n>>  t/test-lib-junit.sh                  | 132 +++++++++++++++++++++++++++\n>>  t/test-lib.sh                        | 128 ++++----------------------\n>>  8 files changed, 287 insertions(+), 136 deletions(-)\n>>  create mode 100644 t/test-lib-github-workflow-markup.sh\n>>  create mode 100644 t/test-lib-junit.sh\n>>\n>>\n>> base-commit: af4e5f569bc89f356eb34a9373d7f82aca6faa8a\n>> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1117%2Fdscho%2Fuse-grouping-in-ci-v1\n>> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1117/dscho/use-grouping-in-ci-v1\n>> Pull-Request: https://github.com/gitgitgadget/git/pull/1117\n>> --\n>> gitgitgadget\n>>\n>>\n\n"},{"id":"448900","messageId":"nycvar.QRO.7.76.6.2202201623500.26495@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"xmqqtucuw93i.fsf@gitster.g","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-02-20T15:25:42Z","receivedAt":"2022-02-20T15:25:51Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sat, 19 Feb 2022, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n> > I notice that you did not take this into `seen` yet. I find that a little\n> > sad because it would potentially have helped others to figure out the\n> > failure in the latest `seen`:\n> > https://github.com/git/git/runs/5255378056?check_suite_focus=true#step:5:162\n> >\n> > Essentially, a recent patch introduces hard-coded SHA-1 hashes in t3007.3.\n>\n> I saw the thread, I saw a few patches were commented on, and a few\n> were left unanswered, but one was replied by the original submitter\n> with a \"Good catch!\", making me expect the topic to be discussed or\n> rerolled to become ready relatively soon.\n\nYes, I have local changes, but I had really hoped that this patch series\nwould get a chance to prove its point by example, i.e. by offering the\nimproved output for the failures in `seen`. I hoped that because I think\nthat those improvements speak for themselves when you see them.\n\nCiao,\nDscho\n"},{"id":"448956","messageId":"220221.867d9od48e.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2202201623500.26495@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-02-21T08:09:54Z","receivedAt":"2022-02-21T08:16:26Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Feb 20 2022, Johannes Schindelin wrote:\n\n> Hi Junio,\n>\n> On Sat, 19 Feb 2022, Junio C Hamano wrote:\n>\n>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>>\n>> > I notice that you did not take this into `seen` yet. I find that a little\n>> > sad because it would potentially have helped others to figure out the\n>> > failure in the latest `seen`:\n>> > https://github.com/git/git/runs/5255378056?check_suite_focus=true#step:5:162\n>> >\n>> > Essentially, a recent patch introduces hard-coded SHA-1 hashes in t3007.3.\n>>\n>> I saw the thread, I saw a few patches were commented on, and a few\n>> were left unanswered, but one was replied by the original submitter\n>> with a \"Good catch!\", making me expect the topic to be discussed or\n>> rerolled to become ready relatively soon.\n>\n> Yes, I have local changes, but I had really hoped that this patch series\n> would get a chance to prove its point by example, i.e. by offering the\n> improved output for the failures in `seen`. I hoped that because I think\n> that those improvements speak for themselves when you see them.\n\nI think it's a good idea to get wider expose in \"seen\", \"next\" etc. for\ntopics where the bottleneck is lack of feedback due to lack of wider\nexposure.\n\nBut in this case I've pointed out both direction & UX issues to you that\nyou haven't addressed. Both what I sent a reminder of yesterday in [1],\nand more relevant to what you're discussing here a reply [2] where I\nlooked & tested your new output v.s. the old, and found that on test\nfailures it:\n\n * Replaced summary output with a much more verbose version.\n\n * Turned the GitHub UI from usable (but sometimes hard to find the needle in\n   the haystack) to *extremely slow*. Seemingly because the browser was asked to\n   make sense of~30k lines of output, with some of it hidden dynamically by JavaScript.\n\n1. https://lore.kernel.org/git/220220.86bkz1d7hm.gmgdl@evledraar.gmail.com/\n2. https://lore.kernel.org/git/220126.86sftbfjl4.gmgdl@evledraar.gmail.com/\n"},{"id":"449100","messageId":"nycvar.QRO.7.76.6.2202221124070.4418@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"220221.867d9od48e.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-02-22T10:26:35Z","receivedAt":"2022-02-22T10:26:47Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ævar,\n\nOn Mon, 21 Feb 2022, Ævar Arnfjörð Bjarmason wrote:\n\n> On Sun, Feb 20 2022, Johannes Schindelin wrote:\n>\n> > On Sat, 19 Feb 2022, Junio C Hamano wrote:\n> >\n> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> >>\n> >> > I notice that you did not take this into `seen` yet. I find that a little\n> >> > sad because it would potentially have helped others to figure out the\n> >> > failure in the latest `seen`:\n> >> > https://github.com/git/git/runs/5255378056?check_suite_focus=true#step:5:162\n> >> >\n> >> > Essentially, a recent patch introduces hard-coded SHA-1 hashes in t3007.3.\n> >>\n> >> I saw the thread, I saw a few patches were commented on, and a few\n> >> were left unanswered, but one was replied by the original submitter\n> >> with a \"Good catch!\", making me expect the topic to be discussed or\n> >> rerolled to become ready relatively soon.\n> >\n> > Yes, I have local changes, but I had really hoped that this patch series\n> > would get a chance to prove its point by example, i.e. by offering the\n> > improved output for the failures in `seen`. I hoped that because I think\n> > that those improvements speak for themselves when you see them.\n>\n> I think it's a good idea to get wider expose in \"seen\", \"next\" etc. for\n> topics where the bottleneck is lack of feedback due to lack of wider\n> exposure.\n\nHaving this in `seen` will give the patch series a chance to show in real\nlife how it improves the process of analyzing regressions.\n\nCiao,\nJohannes\n"},{"id":"449101","messageId":"nycvar.QRO.7.76.6.2202221126450.4418@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"220220.86bkz1d7hm.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-02-22T10:30:25Z","receivedAt":"2022-02-22T10:30:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ævar,\n\nOn Sun, 20 Feb 2022, Ævar Arnfjörð Bjarmason wrote:\n\n> On Sun, Feb 20 2022, Johannes Schindelin wrote:\n>\n> > I notice that you did not take this into `seen` yet. I find that a little\n> > sad because it would potentially have helped others to figure out the\n> > failure in the latest `seen`:\n> > https://github.com/git/git/runs/5255378056?check_suite_focus=true#step:5:162\n> >\n> > Essentially, a recent patch introduces hard-coded SHA-1 hashes in t3007.3.\n>\n> I left some feedback on your submission ~3 weeks ago that you haven't\n> responded to:\n> https://lore.kernel.org/git/220127.86ilu5cdnf.gmgdl@evledraar.gmail.com/\n\nYou answered my goal of making it easier to figure out regressions by\ndoubling down on hiding the logs even better. That's not feedback, that's\njust ignoring the goal.\n\nYou answered my refactor of the Azure Pipelines support with the question\n\"why?\" that I had answered already a long time ago. That's not feedback,\nthat's ignoring the answers I already provided.\n\nI don't know how to respond to that, therefore I didn't.\n\nCiao,\nJohannes\n"},{"id":"449135","messageId":"220222.86tucr6kz5.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2202221126450.4418@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-02-22T13:31:10Z","receivedAt":"2022-02-22T14:21:09Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Feb 22 2022, Johannes Schindelin wrote:\n\n> Hi Ævar,\n>\n> On Sun, 20 Feb 2022, Ævar Arnfjörð Bjarmason wrote:\n>\n>> On Sun, Feb 20 2022, Johannes Schindelin wrote:\n>>\n>> > I notice that you did not take this into `seen` yet. I find that a little\n>> > sad because it would potentially have helped others to figure out the\n>> > failure in the latest `seen`:\n>> > https://github.com/git/git/runs/5255378056?check_suite_focus=true#step:5:162\n>> >\n>> > Essentially, a recent patch introduces hard-coded SHA-1 hashes in t3007.3.\n>>\n>> I left some feedback on your submission ~3 weeks ago that you haven't\n>> responded to:\n>> https://lore.kernel.org/git/220127.86ilu5cdnf.gmgdl@evledraar.gmail.com/\n>\n> You answered my goal of making it easier to figure out regressions by\n> doubling down on hiding the logs even better. That's not feedback, that's\n> just ignoring the goal.\n\nI think it's clear to anyone reading my feedback that that's either a\ngross misreading of the feedback I provided or an intentional\nmisrepresentation.\n\nI don't mention the second one of those lightly, but I think after some\nmonths of that pattern now when commenting on various patches of yours\nit's not an unfair claim.\n\nI.e. you generally seem to latch onto some very narrow interpretation or\ncomment in some larger feedback pointing out various issues to you, and\nuse that as a reason not to respond to or address any of the rest.\n\nSo just to make the point about one of those mentioned in my [1] with\nsome further details (I won't go into the whole thing to avoid repeating\nmyself):\n\nI opened both of:\n\n    https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true\n    https://github.com/dscho/git/runs/4840190622?check_suite_focus=true\n\nJust now in Firefox 91.5.0esr-1. Both having been opened before, so\nthey're in cache, and I've got a current 40MB/s real downlink speed etc.\n\nThe former fully loads in around 5100ms, with your series here that's\njust short of 18000ms.\n\nSo your CI changes are making the common case of just looking at a CI\nfailure more than **3x as slow as before**.\n\nThat's according to the \"performance\" timeline, and not some abstract\n\"some JS was still running in the background\". It lines up with the time\nthat the scroll bar on the side of the screen stops moving, and the\nviewport does the \"zoom to end\" thing in GitHub CI's UI, focusing on the\nerror reported. It was really slow before, but it's SLOOOOOW now.\n\nAll of which (and I'm no webdev expert) seems to do with the browser\nengine struggling to keep up with a much larger set of log data being\nthrown at it, which despite the eliding you're adding can be seen in the\n~1.7k lines of output growing to beyond ~33k now.\n\nOnce it loads the end result after all of that (re your \"doubling down\non hiding the logs even better\") is that I need to (and I've got a\nsizable vertically mounted screen) scroll through around 6 pages of\noutput, each of which takes around 3 seconds of Firefox churning on more\nthan 100% CPU before it shows me the next page.\n\nAnd even *if* it was instant the names of the failing tests are now\nspread across several pages of output, whereas in the \"prove\" output we\nhave a quick overall summary separated from the\n\"ci/print-test-failures.sh\" output\n\nDoes that mean the current output is perfect and can't be improved? No,\nI also think it sucks. I just think that the current implementation\nyou've proposed for improving it is making it worse overall.\n\nWhich doesn't mean that it couldn't be addressed, fixed, or that the\ncore idea of using that \"group\" syntax to aggregate that output into\nsections is bad. I think we should use it, just not as it's currently\nimplemented.\n\nIf that's \"not feedback\" I don't know what is. It's all relevant, and\nwhile I'm elaborating further here [1] sent almost a month ago notes the\nsame issues.\n\n> You answered my refactor of the Azure Pipelines support with the question\n> \"why?\" that I had answered already a long time ago. That's not feedback,\n> that's ignoring the answers I already provided.\n\nI think it's clear what the gap between that answer is and what I was\nasking you was in the parallel follow-up discussion at [2].\n\nBut even your answer there of just wanting to keep it in place doesn't\nreally answer that question for this series. You're not just keeping\nthat stale code in place, but actively changing it.\n\nI.e. even if you run with all that how are others meant to test and\nreview the changes being proposed here?\n\nI.e. is resurrecting Azure CI required to test this series, or should\nreviewers ignore those parts and just hope it all works etc?\n\n> I don't know how to respond to that, therefore I didn't.\n\nI think whatever differences in direction for this CI feature that we\nhave, or troubles understanding one another, that your update after 3\nweeks of not replying to that feedback [3] asking why Junio didn't pick\nup your patches being indistinguishable from there having been nothing\nsaid about your patches at all is, I think, not a good way to proceed\nwith that.\n\nI.e. we're not the only people talking here, there's presumably others\nwho'll read these threads and will want to comment on the direction of\nany CI changes.\n\nKnowing from you that you read outstanding feedback and didn't\nunderstand it, or read it and summarized but ultimately decided to\nchange nothing etc. makes for much of a flow on the ML than just\nignoring that feedback entirely.\n\n1. https://lore.kernel.org/git/220126.86sftbfjl4.gmgdl@evledraar.gmail.com/\n2. https://lore.kernel.org/git/220222.86y2236ndp.gmgdl@evledraar.gmail.com/\n3. https://lore.kernel.org/git/nycvar.QRO.7.76.6.2202200043590.26495@tvgsbejvaqbjf.bet/\n"},{"id":"449238","messageId":"505afc19-25bd-7ccb-7fb2-26bcc9d47119@gmail.com","threadId":"57297","inReplyTo":"220222.86tucr6kz5.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2022-02-23T12:07:13Z","receivedAt":"2022-02-23T12:07:46Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 22/02/2022 13:31, Ævar Arnfjörð Bjarmason wrote:\n> [...]\n> So just to make the point about one of those mentioned in my [1] with\n> some further details (I won't go into the whole thing to avoid repeating\n> myself):\n> \n> I opened both of:\n> \n>      https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true\n>      https://github.com/dscho/git/runs/4840190622?check_suite_focus=true\n> \n> Just now in Firefox 91.5.0esr-1. Both having been opened before, so\n> they're in cache, and I've got a current 40MB/s real downlink speed etc.\n> \n> The former fully loads in around 5100ms, with your series here that's\n> just short of 18000ms.\n> \n> So your CI changes are making the common case of just looking at a CI\n> failure more than **3x as slow as before**.\n\nI don't think that is the most useful comparison between the two. When I \nam investigating a test failure the time that matters to me is the time \nit takes to display the output of the failing test case. With the first \nlink above the initial page load is faster but to get to the output of \nthe failing test case I have click on \"Run ci/print_test_failures.sh\" \nthen wait for that to load and then search for \"not ok\" to actually get \nto the information I'm after. With the second link the initial page load \ndoes feel slower but then I'm presented  with the test failures nicely \nhighlighted in red, all I have to do is click on one and I've got the \ninformation I'm after. Overall that is much faster and easier to use.\n\nBest Wishes\n\nPhillip\n"},{"id":"449240","messageId":"f73586a9-e9f1-aa1d-ac22-8102e6583e2b@gmail.com","threadId":"57297","inReplyTo":"9333ba781b8240f704e739b00d274f8c3d887e39.1643050574.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 4/9] ci/run-build-and-tests: add some structure to the GitHub workflow output","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2022-02-23T12:13:51Z","receivedAt":"2022-02-23T12:14:00Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Dscho\n\nOn 24/01/2022 18:56, Johannes Schindelin via GitGitGadget wrote:\n> From: Johannes Schindelin <johannes.schindelin@gmx.de>\n> \n> The current output of Git's GitHub workflow can be quite confusing,\n> especially for contributors new to the project.\n> \n> To make it more helpful, let's introduce some collapsible grouping.\n> Initially, readers will see the high-level view of what actually\n> happened (did the build fail, or the test suite?). To drill down, the\n> respective group can be expanded.\n> \n> Note: sadly, workflow output currently cannot contain any nested groups\n> (see https://github.com/actions/runner/issues/802 for details),\n> therefore we take pains to ensure to end any previous group before\n> starting a new one.\n\nThanks for working on this, I find it makes it much easier to get to the \ninformation I need when a test fails. I'm not familiar with github's \ngrouping but I noticed something below I didn't understand.\n\n> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> ---\n>   ci/lib.sh                 | 55 ++++++++++++++++++++++++++++++++++-----\n>   ci/run-build-and-tests.sh |  4 +--\n>   ci/run-test-slice.sh      |  2 +-\n>   3 files changed, 51 insertions(+), 10 deletions(-)\n> \n> diff --git a/ci/lib.sh b/ci/lib.sh\n> index 2b2c0932320..4ed8f40ab02 100755\n> --- a/ci/lib.sh\n> +++ b/ci/lib.sh\n> @@ -1,5 +1,49 @@\n>   # Library of functions shared by all CI scripts\n>   \n> +if test true != \"$GITHUB_ACTIONS\"\n> +then\n> +\tbegin_group () { :; }\n> +\tend_group () { :; }\n> +\n> +\tgroup () {\n> +\t\tshift\n> +\t\t\"$@\"\n> +\t}\n> +\tset -x\n> +else\n> +\tbegin_group () {\n> +\t\tneed_to_end_group=t\n> +\t\techo \"::group::$1\" >&2\n> +\t\tset -x\n> +\t}\n> +\n> +\tend_group () {\n> +\t\ttest -n \"$need_to_end_group\" || return 0\n> +\t\tset +x\n> +\t\tneed_to_end_group=\n> +\t\techo '::endgroup::' >&2\n> +\t}\n> +\ttrap end_group EXIT\n> +\n> +\tgroup () {\n> +\t\tset +x\n> +\t\tbegin_group \"$1\"\n> +\t\tshift\n> +\t\t\"$@\"\n> +\t\tres=$?\n> +\t\tend_group\n> +\t\treturn $res\n> +\t}\n> +\n> +\tbegin_group \"CI setup\"\n> +fi\n> +\n> +# Set 'exit on error' for all CI scripts to let the caller know that\n> +# something went wrong.\n> +# Set tracing executed commands, primarily setting environment variables\n> +# and installing dependencies.\n> +set -e\n\nThe comment is moved unchanged but the set command has lost the \"-x\". We \nnow have several \"set -x\" commands in the functions above and one below \n\"end_group\" lower down. Does the comment need updating as we are not \nenabling the tracing of executed commands here anymore?\n\nBest Wishes\n\nPhillip\n\n>   skip_branch_tip_with_tag () {\n>   \t# Sometimes, a branch is pushed at the same time the tag that points\n>   \t# at the same commit as the tip of the branch is pushed, and building\n> @@ -88,12 +132,6 @@ export TERM=${TERM:-dumb}\n>   # Clear MAKEFLAGS that may come from the outside world.\n>   export MAKEFLAGS=\n>   \n> -# Set 'exit on error' for all CI scripts to let the caller know that\n> -# something went wrong.\n> -# Set tracing executed commands, primarily setting environment variables\n> -# and installing dependencies.\n> -set -ex\n> -\n>   if test -n \"$SYSTEM_COLLECTIONURI\" || test -n \"$SYSTEM_TASKDEFINITIONSURI\"\n>   then\n>   \tCI_TYPE=azure-pipelines\n> @@ -138,7 +176,7 @@ then\n>   \t\t\ttest_name=\"${test_exit%.exit}\"\n>   \t\t\ttest_name=\"${test_name##*/}\"\n>   \t\t\tprintf \"\\\\e[33m\\\\e[1m=== Failed test: ${test_name} ===\\\\e[m\\\\n\"\n> -\t\t\tcat \"t/test-results/$test_name.out\"\n> +\t\t\tgroup \"Failed test: $test_name\" cat \"t/test-results/$test_name.out\"\n>   \n>   \t\t\ttrash_dir=\"t/trash directory.$test_name\"\n>   \t\t\tcp \"t/test-results/$test_name.out\" t/failed-test-artifacts/\n> @@ -234,3 +272,6 @@ linux-leaks)\n>   esac\n>   \n>   MAKEFLAGS=\"$MAKEFLAGS CC=${CC:-cc}\"\n> +\n> +end_group\n> +set -x\n> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\n> index e49f9eaa8c0..5516f45f7fe 100755\n> --- a/ci/run-build-and-tests.sh\n> +++ b/ci/run-build-and-tests.sh\n> @@ -48,10 +48,10 @@ esac\n>   # Any new \"test\" targets should not go after this \"make\", but should\n>   # adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n>   # start running tests.\n> -make\n> +group Build make\n>   if test -n \"$run_tests\"\n>   then\n> -\tmake test ||\n> +\tgroup \"Run tests\" make test ||\n>   \thandle_failed_tests\n>   fi\n>   check_unignored_build_artifacts\n> diff --git a/ci/run-test-slice.sh b/ci/run-test-slice.sh\n> index 63358c23e11..a3c67956a8d 100755\n> --- a/ci/run-test-slice.sh\n> +++ b/ci/run-test-slice.sh\n> @@ -10,7 +10,7 @@ windows*) cmd //c mklink //j t\\\\.prove \"$(cygpath -aw \"$cache_dir/.prove\")\";;\n>   *) ln -s \"$cache_dir/.prove\" t/.prove;;\n>   esac\n>   \n> -make --quiet -C t T=\"$(cd t &&\n> +group \"Run tests\" make --quiet -C t T=\"$(cd t &&\n>   \t./helper/test-tool path-utils slice-tests \"$1\" \"$2\" t[0-9]*.sh |\n>   \ttr '\\n' ' ')\" ||\n>   handle_failed_tests\n\n"},{"id":"449577","messageId":"220225.868rtz85lu.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"505afc19-25bd-7ccb-7fb2-26bcc9d47119@gmail.com","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-02-25T12:39:54Z","receivedAt":"2022-02-25T12:59:16Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Feb 23 2022, Phillip Wood wrote:\n\n> On 22/02/2022 13:31, Ævar Arnfjörð Bjarmason wrote:\n>> [...]\n>> So just to make the point about one of those mentioned in my [1] with\n>> some further details (I won't go into the whole thing to avoid repeating\n>> myself):\n>> I opened both of:\n>>      https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true\n>>      https://github.com/dscho/git/runs/4840190622?check_suite_focus=true\n>> Just now in Firefox 91.5.0esr-1. Both having been opened before, so\n>> they're in cache, and I've got a current 40MB/s real downlink speed etc.\n>> The former fully loads in around 5100ms, with your series here\n>> that's\n>> just short of 18000ms.\n>> So your CI changes are making the common case of just looking at a\n>> CI\n>> failure more than **3x as slow as before**.\n>\n> I don't think that is the most useful comparison between the two.[...]\n\nI'm not saying that it's the most useful comparison between the two, but\nthat there's a major performance regression introduced in this series\nthat so far isn't addressed or noted.\n\n> [...]When\n> I am investigating a test failure the time that matters to me is the\n> time it takes to display the output of the failing test case. With the\n> first link above the initial page load is faster but to get to the\n> output of the failing test case I have click on \"Run\n> ci/print_test_failures.sh\" then wait for that to load and then search\n> for \"not ok\" to actually get to the information I'm after. With the\n> second link the initial page load does feel slower but then I'm\n> presented  with the test failures nicely highlighted in red, all I\n> have to do is click on one and I've got the information I'm\n> after. Overall that is much faster and easier to use.\n\nWhether you think the regression is worth the end result is a subjective\njudgement. I don't think it is, but I don't think you or anyone else is\nwrong if they don't agree.\n\nIf you think it's OK to spend ~20s instead of ~5s on rendering the new\noutput that's something that clearly depends on how much you value the\nnew output, and much much you're willing to wait.\n\nWhat I am saying, and what I hope you'll agree with, is that it's\nsomething that should be addressed in some way by this series.\n\nOne way to do that would be to note the performence regression in a\ncommit message, and argue that despite the slowdown it's worth it.\n"},{"id":"449578","messageId":"nycvar.QRO.7.76.6.2202251439160.11118@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"f73586a9-e9f1-aa1d-ac22-8102e6583e2b@gmail.com","subject":"Re: [PATCH 4/9] ci/run-build-and-tests: add some structure to the GitHub workflow output","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-02-25T13:40:00Z","receivedAt":"2022-02-25T13:40:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip,\n\nOn Wed, 23 Feb 2022, Phillip Wood wrote:\n\n> On 24/01/2022 18:56, Johannes Schindelin via GitGitGadget wrote:\n>\n> > +# Set 'exit on error' for all CI scripts to let the caller know that\n> > +# something went wrong.\n> > +# Set tracing executed commands, primarily setting environment variables\n> > +# and installing dependencies.\n> > +set -e\n>\n> The comment is moved unchanged but the set command has lost the \"-x\". We now\n> have several \"set -x\" commands in the functions above and one below\n> \"end_group\" lower down. Does the comment need updating as we are not enabling\n> the tracing of executed commands here anymore?\n\nOh yes, the comment needs to be updated. Thank you for pointing that out.\n\nCiao,\nDscho\n"},{"id":"449583","messageId":"nycvar.QRO.7.76.6.2202251440330.11118@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"505afc19-25bd-7ccb-7fb2-26bcc9d47119@gmail.com","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-02-25T14:10:46Z","receivedAt":"2022-02-25T14:11:04Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip,\n\nOn Wed, 23 Feb 2022, Phillip Wood wrote:\n\n> On 22/02/2022 13:31, Ævar Arnfjörð Bjarmason wrote:\n> > [...]\n> > So just to make the point about one of those mentioned in my [1] with\n> > some further details (I won't go into the whole thing to avoid repeating\n> > myself):\n> >\n> > I opened both of:\n> >\n> > https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true\n> > https://github.com/dscho/git/runs/4840190622?check_suite_focus=true\n> >\n> > Just now in Firefox 91.5.0esr-1. Both having been opened before, so\n> > they're in cache, and I've got a current 40MB/s real downlink speed etc.\n> >\n> > The former fully loads in around 5100ms, with your series here that's\n> > just short of 18000ms.\n> >\n> > So your CI changes are making the common case of just looking at a CI\n> > failure more than **3x as slow as before**.\n>\n> I don't think that is the most useful comparison between the two. When I\n> am investigating a test failure the time that matters to me is the time\n> it takes to display the output of the failing test case.\n\nThank you for expressing this so clearly. I will adopt a variation of this\nphrasing in my commit message, if you don't mind?\n\n> With the first link above the initial page load is faster but to get to\n> the output of the failing test case I have click on \"Run\n> ci/print_test_failures.sh\" then wait for that to load and then search\n> for \"not ok\" to actually get to the information I'm after.\n\nAnd that's only because you are familiar with what you have to do.\n\nAny new contributor would be stuck with the information presented on the\ninitial load, without any indication that more information _is_ available,\njust hidden away in the next step's log (which is marked as \"succeeding\",\ntherefore misleading the inclined reader into thinking that this cannot\npotentially contain any information pertinent to the _failure_ that needs\nto be investigated).\n\n> With the second link the initial page load does feel slower but then I'm\n> presented with the test failures nicely highlighted in red, all I have\n> to do is click on one and I've got the information I'm after.\n>\n> Overall that is much faster and easier to use.\n\nThank you for your comment. I really started to doubt myself, getting the\nidea that it's just a case of me holding this thing wrong.\n\nFor what it's worth, I did make a grave mistake by using that particular\n`seen` CI failure with all of those failing p4 tests, which obviously\nresulted in an incredibly large amount of logs. Obviously that _must_ be\nslow to load. I just did not have the time to fabricate a CI failure.\n\nHowever, I do agree with you that the large amount of logs would have to\nbe looked at _anyway_, whether it is shown upon loading the job's logs or\nonly when expanding the `print-test-failures` step's logs. The amount of\nthe logs is a constant, after all, I did not change anything there (nor\nwould I).\n\nSo a better example might be my concrete use case yesterday: the CI build\nof `seen` failed. Here is the link to the regular output:\n\n\thttps://github.com/git/git/actions/runs/1890665968\n\nOn that page, you see the following:\n\n\n\tAnnotations\n\t8 errors and 1 warning\n\n\tⓧ win test (3)\n\t  Process completed with exit code 2.\n\n\tⓧ win test (6)\n\t  Process completed with exit code 2.\n\n\tⓧ win test (2)\n\t  Process completed with exit code 2.\n\n\tⓧ win+VS test (3)\n\t  Process completed with exit code 2.\n\n\tⓧ win+VS test (6)\n\t  Process completed with exit code 2.\n\n\tⓧ win+VS test (2)\n\t  Process completed with exit code 2.\n\n\tⓧ osx-gcc (macos-latest)\n\t  Process completed with exit code 2.\n\n\tⓧ osx-clang (macos-latest)\n\t  Process completed with exit code 2.\n\n\t⚠ CI: .github#L1\n\t  windows-latest workflows now use windows-2022. For more details, see https://github.com/actions/virtual-environments/issues/4856\n\nSo I merged my branch into `seen` and pushed it. The corresponding run can\nbe seen here:\n\n\thttps://github.com/dscho/git/actions/runs/1892982393\n\nOn that page, you see the following:\n\n\tAnnotations\n\t50 errors and 1 warning\n\n\tⓧ win test (3)\n\t  failed: t7527.1 explicit daemon start and stop\n\n\tⓧ win test (3)\n\t  failed: t7527.2 implicit daemon start\n\n\tⓧ win test (3)\n\t  failed: t7527.3 implicit daemon stop (delete .git)\n\n\tⓧ win test (3)\n\t  failed: t7527.4 implicit daemon stop (rename .git)\n\n\tⓧ win test (3)\n\t  failed: t7527.5 implicit daemon stop (rename GIT~1)\n\n\tⓧ win test (3)\n\t  failed: t7527.6 implicit daemon stop (rename GIT~2)\n\n\tⓧ win test (3)\n\t  failed: t7527.8 cannot start multiple daemons\n\n\tⓧ win test (3)\n\t  failed: t7527.10 update-index implicitly starts daemon\n\n\tⓧ win test (3)\n\t  failed: t7527.11 status implicitly starts daemon\n\n\tⓧ win test (3)\n\t  failed: t7527.12 edit some files\n\n\tⓧ win test (2)\n\t  failed: t0012.81 fsmonitor--daemon can handle -h\n\n\tⓧ win test (2)\n\t  Process completed with exit code 1.\n\n\tⓧ win test (6)\n\t  failed: t7519.2 run fsmonitor-daemon in bare repo\n\n\tⓧ win test (6)\n\t  failed: t7519.3 run fsmonitor-daemon in virtual repo\n\n\tⓧ win test (6)\n\t  Process completed with exit code 1.\n\n\tⓧ win+VS test (3)\n\t  failed: t7527.1 explicit daemon start and stop\n\n\tⓧ win+VS test (3)\n\t  failed: t7527.2 implicit daemon start\n\n\tⓧ win+VS test (3)\n\t  failed: t7527.3 implicit daemon stop (delete .git)\n\n\tⓧ win+VS test (3)\n\t  failed: t7527.4 implicit daemon stop (rename .git)\n\n\tⓧ win+VS test (3)\n\t  failed: t7527.5 implicit daemon stop (rename GIT~1)\n\n\tⓧ win+VS test (3)\n\t  failed: t7527.6 implicit daemon stop (rename GIT~2)\n\n\tⓧ win+VS test (3)\n\t  failed: t7527.8 cannot start multiple daemons\n\n\tⓧ win+VS test (3)\n\t  failed: t7527.10 update-index implicitly starts daemon\n\n\tⓧ win+VS test (3)\n\t  failed: t7527.11 status implicitly starts daemon\n\n\tⓧ win+VS test (3)\n\t  failed: t7527.12 edit some files\n\n\tⓧ win+VS test (2)\n\t  failed: t0012.81 fsmonitor--daemon can handle -h\n\n\tⓧ win+VS test (2)\n\t  Process completed with exit code 1.\n\n\tⓧ win+VS test (6)\n\t  failed: t7519.2 run fsmonitor-daemon in bare repo\n\n\tⓧ win+VS test (6)\n\t  failed: t7519.3 run fsmonitor-daemon in virtual repo\n\n\tⓧ win+VS test (6)\n\t  Process completed with exit code 1.\n\n\tⓧ osx-clang (macos-latest)\n\t  failed: t0012.81 fsmonitor--daemon can handle -h\n\n\tⓧ osx-clang (macos-latest)\n\t  failed: t7519.2 run fsmonitor-daemon in bare repo\n\n\tⓧ osx-clang (macos-latest)\n\t  failed: t7527.1 explicit daemon start and stop\n\n\tⓧ osx-clang (macos-latest)\n\t  failed: t7527.2 implicit daemon start\n\n\tⓧ osx-clang (macos-latest)\n\t  failed: t7527.3 implicit daemon stop (delete .git)\n\n\tⓧ osx-clang (macos-latest)\n\t  failed: t7527.4 implicit daemon stop (rename .git)\n\n\tⓧ osx-clang (macos-latest)\n\t  failed: t7527.7 MacOS event spelling (rename .GIT)\n\n\tⓧ osx-clang (macos-latest)\n\t  failed: t7527.8 cannot start multiple daemons\n\n\tⓧ osx-clang (macos-latest)\n\t  failed: t7527.10 update-index implicitly starts daemon\n\n\tⓧ osx-clang (macos-latest)\n\t  failed: t7527.11 status implicitly starts daemon\n\n\tⓧ osx-gcc (macos-latest)\n\t  failed: t0012.81 fsmonitor--daemon can handle -h\n\n\tⓧ osx-gcc (macos-latest)\n\t  failed: t7519.2 run fsmonitor-daemon in bare repo\n\n\tⓧ osx-gcc (macos-latest)\n\t  failed: t7527.1 explicit daemon start and stop\n\n\tⓧ osx-gcc (macos-latest)\n\t  failed: t7527.2 implicit daemon start\n\n\tⓧ osx-gcc (macos-latest)\n\t  failed: t7527.3 implicit daemon stop (delete .git)\n\n\tⓧ osx-gcc (macos-latest)\n\t  failed: t7527.4 implicit daemon stop (rename .git)\n\n\tⓧ osx-gcc (macos-latest)\n\t  failed: t7527.7 MacOS event spelling (rename .GIT)\n\n\tⓧ osx-gcc (macos-latest)\n\t  failed: t7527.8 cannot start multiple daemons\n\n\tⓧ osx-gcc (macos-latest)\n\t  failed: t7527.10 update-index implicitly starts daemon\n\n\tⓧ osx-gcc (macos-latest)\n\t  failed: t7527.11 status implicitly starts daemon\n\n\t⚠ CI: .github#L1\n\t  windows-latest workflows now use windows-2022. For more details, see https://github.com/actions/virtual-environments/issues/4856\n\nIn my mind, this is already an improvement. (Even if this is a _lot_ of\noutput, and a lot of individual errors, given that all of them are fixed\nwith a single, small patch to adjust an option usage string, but that's\nnot the fault of my patch series, but of the suggestion to put the check\nfor the option usage string linting into the `parse_options()` machinery\ninstead of into the static analysis job.)\n\nSince there are still plenty of failures, the page admittedly does load\nrelatively slowly. But that's not the time I was trying to optimize for.\nMy time comes at quite a premium these days, so if the computer has to\nwork a little harder while I can do something else, as long as it saves\n_me_ time, I'll take that time. Every time.\n\nCiao,\nDscho\n"},{"id":"449616","messageId":"xmqqv8x2dd7j.fsf@gitster.g","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2202251440330.11118@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-02-25T18:16:00Z","receivedAt":"2022-02-25T18:16:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> So I merged my branch into `seen` and pushed it. The corresponding run can\n> be seen here:\n>\n> \thttps://github.com/dscho/git/actions/runs/1892982393\n\nI visited this page (while logged in to GItHub---I am saying this\nfor others who may not know the output is shown differently for\nvisitors that are logged-in, and and logged-in users).\n\n> On that page, you see the following:\n>\n> \tAnnotations\n> \t50 errors and 1 warning\n>\n> \tⓧ win test (3)\n> \t  failed: t7527.1 explicit daemon start and stop\n> ...\n>\n> \t⚠ CI: .github#L1\n> \t  windows-latest workflows now use windows-2022. For more details, see https://github.com/actions/virtual-environments/issues/4856\n>\n> In my mind, this is already an improvement. (Even if this is a _lot_ of\n> output, and a lot of individual errors, given that all of them are fixed\n> with a single, small patch to adjust an option usage string, but that's\n> not the fault of my patch series, but of the suggestion to put the check\n> for the option usage string linting into the `parse_options()` machinery\n> instead of into the static analysis job.)\n\nIt is not obvious what aspect in the new output _you_ found \"an\nimprovement\" to your readers, because you didn't spell it out.  That\nmakes \"in my mind, this is already an improvement\" a claim that is\nunnecessarily weaker than it really is.\n\nLet me tell my experience:\n\n - Clicking on macos+clang in the map-looking thing, it did show and\n   scroll down automatically to show the last failure link ready to\n   be clicked after a few seconds, which was nice, but made me\n   scroll back to see the first failure, which could have been\n   better.\n\n - Clicking on win+VS test (2), the failed <test> part was\n   automatically opened, and a circle spinned for several dozens of\n   seconds to make me wait, but after that, nothing happened.  It\n   was somewhat hard to know if I were expected to do something to\n   view the first error and when the UI is ready to let me do so, or\n   if I were just expected to wait a bit longer for it to all happen\n   automatically.\n\nEither case, the presentation to fold all the pieces that finished\nsuccessfully made it usable, as that saved human time to scan to\nwhere failures are shown.\n\nI personally do not care about the initial latency when viewing the\noutput from CI run that may have happened a few dozens of minutes\nago (I do not sit in front of GitHub CI UI and wait until it\nfinishes). As long as it is made clear when I can start interacting\nwith it, I can just open the page and let it load while I am working\non something else.\n\nThanks.\n"},{"id":"449676","messageId":"xmqqzgmd5uzu.fsf@gitster.g","threadId":"57297","inReplyTo":"xmqqv8x2dd7j.fsf@gitster.g","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-02-26T18:43:33Z","receivedAt":"2022-02-26T18:43:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Let me tell my experience:\n>\n>  - Clicking on macos+clang in the map-looking thing, it did show and\n>    scroll down automatically to show the last failure link ready to\n>    be clicked after a few seconds, which was nice, but made me\n>    scroll back to see the first failure, which could have been\n>    better.\n>\n>  - Clicking on win+VS test (2), the failed <test> part was\n>    automatically opened, and a circle spinned for several dozens of\n>    seconds to make me wait, but after that, nothing happened.  It\n>    was somewhat hard to know if I were expected to do something to\n>    view the first error and when the UI is ready to let me do so, or\n>    if I were just expected to wait a bit longer for it to all happen\n>    automatically.\n>\n> Either case, the presentation to fold all the pieces that finished\n> successfully made it usable, as that saved human time to scan to\n> where failures are shown.\n>\n> I personally do not care about the initial latency when viewing the\n> output from CI run that may have happened a few dozens of minutes\n> ago (I do not sit in front of GitHub CI UI and wait until it\n> finishes). As long as it is made clear when I can start interacting\n> with it, I can just open the page and let it load while I am working\n> on something else.\n\nFWIW, CI run on \"seen\" uses this series.\n\nWhen I highlight a failure at CI, I often give a URL like this:\n\nhttps://github.com/git/git/runs/5343133021?check_suite_focus=true#step:4:5520\n\nI notice that this \"hide by default\" forces the recipient of the URL\nto click the line after the line with a red highlight before they\ncan view the breakage.\n\nFor example, an URL to show a similar breakage from the old run\n(without this series) looks like this:\n\nhttps://github.com/git/git/runs/5341052811?check_suite_focus=true#step:5:3968\n\nThis directly jumps to the error and the recipient of the URL does\nnot have to do anything special, which I have been using as a\nconvenient way to give developers a starting point.\n\nI haven't compared the implementation of this one and Ævar's series\nthat aims for a different goal, so I do not yet have an opinion on\nwhich one should come first (if we want to achieve both of what each\nof them wants to achieve, that is).\n\nThanks.\n\n"},{"id":"449849","messageId":"xmqqee3mwf7k.fsf@gitster.g","threadId":"57297","inReplyTo":"xmqqzgmd5uzu.fsf@gitster.g","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-01T02:59:11Z","receivedAt":"2022-03-01T02:59:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> FWIW, CI run on \"seen\" uses this series.\n\nAnother \"early impression\".  I had to open this one today,\n\n    https://github.com/git/git/runs/5367854000?check_suite_focus=true\n\nwhich was a jarring experience.  It correctly painted the fourth\ncircle \"Run ci/run-build-and-tests.sh\" in red with X in it, and\nafter waiting for a while (which I already said that I do not mind\nat all), showed a bunch of line, and then auto-scrolled down to the\nend of that section.\n\nIt _looked_ like that it was now ready for me to interact with it,\nso I started to scroll up to the beginning of that section, but I\nhad to stare at blank space for several minutes before lines are\nshown to occupy that space.  During the repainting, unlike the\ninitial delay-wait that lets me know that it is not ready by showing\nthe spinning circle, there was no indication that it wants me to\nwait until it fills the blank space with lines.  Not very pleasant.\n\nI do not think it is so bad to say that it is less pleasant than\nopening the large \"print test failures\" section and looking for \"not\nok\", which was what the original CI UI we had before this series.\nBut at least with the old one, once the UI becomes ready for me to\ninteract with, I didn't have to wait for (for the lack of better\nphrase) such UI hiccups.  Responses to looking for the next instance\nof \"not ok\" was predictable.\n\nThanks.\n"},{"id":"449868","messageId":"xmqq35k2w56n.fsf@gitster.g","threadId":"57297","inReplyTo":"xmqqee3mwf7k.fsf@gitster.g","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-01T06:35:44Z","receivedAt":"2022-03-01T06:35:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> FWIW, CI run on \"seen\" uses this series.\n>\n> Another \"early impression\".  I had to open this one today,\n>\n>     https://github.com/git/git/runs/5367854000?check_suite_focus=true\n>\n> which was a jarring experience.  It correctly painted the fourth\n> circle \"Run ci/run-build-and-tests.sh\" in red with X in it, and\n> after waiting for a while (which I already said that I do not mind\n> at all), showed a bunch of line, and then auto-scrolled down to the\n> end of that section.\n>\n> It _looked_ like that it was now ready for me to interact with it,\n> so I started to scroll up to the beginning of that section, but I\n> had to stare at blank space for several minutes before lines are\n\nNah, that was several seconds, not minutes.  Even though I am on\nChromebooks, they are not _that_ slow ;-)\n\n> shown to occupy that space.  During the repainting, unlike the\n> initial delay-wait that lets me know that it is not ready by showing\n> the spinning circle, there was no indication that it wants me to\n> wait until it fills the blank space with lines.  Not very pleasant.\n>\n> I do not think it is so bad to say that it is less pleasant than\n> opening the large \"print test failures\" section and looking for \"not\n> ok\", which was what the original CI UI we had before this series.\n> But at least with the old one, once the UI becomes ready for me to\n> interact with, I didn't have to wait for (for the lack of better\n> phrase) such UI hiccups.  Responses to looking for the next instance\n> of \"not ok\" was predictable.\n>\n> Thanks.\n"},{"id":"449905","messageId":"nycvar.QRO.7.76.6.2203011109050.11118@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"xmqqzgmd5uzu.fsf@gitster.g","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-03-01T10:10:19Z","receivedAt":"2022-03-01T10:10:31Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sat, 26 Feb 2022, Junio C Hamano wrote:\n\n> When I highlight a failure at CI, I often give a URL like this:\n>\n> https://github.com/git/git/runs/5343133021?check_suite_focus=true#step:4:5520\n>\n> I notice that this \"hide by default\" forces the recipient of the URL\n> to click the line after the line with a red highlight before they\n> can view the breakage.\n\nYes, that's because line 5520 is the header of that group. If you direct\nthe reader to\nhttps://github.com/git/git/runs/5343133021?check_suite_focus=true#step:4:5674\ninstead, it will get expanded.\n\nIf it would not get expanded, that would be a bug, but obviously not in my\npatch series.\n\nCiao,\nDscho\n"},{"id":"449906","messageId":"nycvar.QRO.7.76.6.2203011111150.11118@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"xmqqee3mwf7k.fsf@gitster.g","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-03-01T10:18:07Z","receivedAt":"2022-03-01T10:18:31Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Mon, 28 Feb 2022, Junio C Hamano wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n> > FWIW, CI run on \"seen\" uses this series.\n>\n> Another \"early impression\".  I had to open this one today,\n>\n>     https://github.com/git/git/runs/5367854000?check_suite_focus=true\n>\n> which was a jarring experience.  It correctly painted the fourth\n> circle \"Run ci/run-build-and-tests.sh\" in red with X in it, and\n> after waiting for a while (which I already said that I do not mind\n> at all), showed a bunch of line, and then auto-scrolled down to the\n> end of that section.\n>\n> It _looked_ like that it was now ready for me to interact with it,\n> so I started to scroll up to the beginning of that section, but I\n> had to stare at blank space for several minutes before lines are\n> shown to occupy that space.  During the repainting, unlike the\n> initial delay-wait that lets me know that it is not ready by showing\n> the spinning circle, there was no indication that it wants me to\n> wait until it fills the blank space with lines.  Not very pleasant.\n>\n> I do not think it is so bad to say that it is less pleasant than\n> opening the large \"print test failures\" section and looking for \"not\n> ok\", which was what the original CI UI we had before this series.\n> But at least with the old one, once the UI becomes ready for me to\n> interact with, I didn't have to wait for (for the lack of better\n> phrase) such UI hiccups.  Responses to looking for the next instance\n> of \"not ok\" was predictable.\n\nLet me again state my goal clearly, because some readers seem to be\nconfused and believe that I want to improve the developer experience of\nveterans of the Git mailing list who are more than capable of finding\ntheir way through the build failures.\n\nMy goal is instead to make new contributors' lives easier.\n\nIt is a pretty high bar we set, expecting a new contributor faced with a\nbuild failure to figure out how to fix the breakage. It's as if we\n_wanted_ to instill impostors' syndrome in them, which is probably not\nintentional.\n\nIn that respect, a relatively responsive page that utterly fails to direct\nthe reader to the culprit is far, far worse than a slightly bumpy page\nthat _does_ lead the reader in the right direction.\n\nIn any case, thank you for integrating the patches into `seen` so that the\nimpact of the patches can be \"seen\".\n\nCiao,\nDscho\n"},{"id":"449907","messageId":"nycvar.QRO.7.76.6.2203011119000.11118@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"xmqqv8x2dd7j.fsf@gitster.g","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-03-01T10:20:46Z","receivedAt":"2022-03-01T10:20:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Fri, 25 Feb 2022, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n> > On that page, you see the following:\n> >\n> > \tAnnotations\n> > \t50 errors and 1 warning\n> >\n> > \tⓧ win test (3)\n> > \t  failed: t7527.1 explicit daemon start and stop\n> > ...\n> >\n> > \t⚠ CI: .github#L1\n> > \t  windows-latest workflows now use windows-2022. For more details, see https://github.com/actions/virtual-environments/issues/4856\n> >\n> > In my mind, this is already an improvement. (Even if this is a _lot_ of\n> > output, and a lot of individual errors, given that all of them are fixed\n> > with a single, small patch to adjust an option usage string, but that's\n> > not the fault of my patch series, but of the suggestion to put the check\n> > for the option usage string linting into the `parse_options()` machinery\n> > instead of into the static analysis job.)\n>\n> It is not obvious what aspect in the new output _you_ found \"an\n> improvement\" to your readers, because you didn't spell it out.\n\nTrue.\n\nThe difference is those added lines that clearly indicate not only the\nfailed job, but also the precise test case that failed. All in the summary\npage, without requiring any clicking nor scrolling.\n\nThank you,\nDscho\n"},{"id":"449908","messageId":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.git.1643050574.gitgitgadget@gmail.com","subject":"[PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-03-01T10:24:40Z","receivedAt":"2022-03-01T10:24:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Changes since v1:\n\n * In the patch that removed MAKE_TARGETS, a stale comment about that\n   variable is also removed.\n * The comment about set -x has been adjusted because it no longer applies\n   as-is.\n * The commit message of \"ci: make it easier to find failed tests' logs in\n   the GitHub workflow\" has been adjusted to motivate the improvement\n   better.\n\n\nBackground\n==========\n\nRecent patches intended to help readers figure out CI failures much quicker\nthan before. Unfortunately, they haven't been entirely positive for me. For\nexample, they broke the branch protections in Microsoft's fork of Git, where\nwe require Pull Requests to pass a certain set of Checks (which are\nidentified by their names) and therefore caused follow-up work.\n\nUsing CI and in general making it easier for new contributors is an area I'm\npassionate about, and one I'd like to see improved.\n\n\nThe current situation\n=====================\n\nLet me walk you through the current experience when a PR build fails: I get\na notification mail that only says that a certain job failed. There's no\nindication of which test failed (or was it the build?). I can click on a\nlink at it takes me to the workflow run. Once there, all it says is \"Process\ncompleted with exit code 1\", or even \"code 2\". Sure, I can click on one of\nthe failed jobs. It even expands the failed step's log (collapsing the other\nsteps). And what do I see there?\n\nLet's look at an example of a failed linux-clang (ubuntu-latest) job\n[https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true]:\n\n[...]\nTest Summary Report\n-------------------\nt1092-sparse-checkout-compatibility.sh           (Wstat: 256 Tests: 53 Failed: 1)\n  Failed test:  49\n  Non-zero exit status: 1\nt3701-add-interactive.sh                         (Wstat: 0 Tests: 71 Failed: 0)\n  TODO passed:   45, 47\nFiles=957, Tests=25489, 645 wallclock secs ( 5.74 usr  1.56 sys + 866.28 cusr 364.34 csys = 1237.92 CPU)\nResult: FAIL\nmake[1]: *** [Makefile:53: prove] Error 1\nmake[1]: Leaving directory '/home/runner/work/git/git/t'\nmake: *** [Makefile:3018: test] Error 2\n\n\nThat's it. I count myself lucky not to be a new contributor being faced with\nsomething like this.\n\nNow, since I am active in the Git project for a couple of days or so, I can\nmake sense of the \"TODO passed\" label and know that for the purpose of\nfixing the build failures, I need to ignore this, and that I need to focus\non the \"Failed test\" part instead.\n\nI also know that I do not have to get myself an ubuntu-latest box just to\nreproduce the error, I do not even have to check out the code and run it\njust to learn what that \"49\" means.\n\nI know, and I do not expect any new contributor, not even most seasoned\ncontributors to know, that I have to patiently collapse the \"Run\nci/run-build-and-tests.sh\" job's log, and instead expand the \"Run\nci/print-test-failures.sh\" job log (which did not fail and hence does not\ndraw any attention to it).\n\nI know, and again: I do not expect many others to know this, that I then\nhave to click into the \"Search logs\" box (not the regular web browser's\nsearch via Ctrl+F!) and type in \"not ok\" to find the log of the failed test\ncase (and this might still be a \"known broken\" one that is marked via\ntest_expect_failure and once again needs to be ignored).\n\nTo be excessively clear: This is not a great experience!\n\n\nImproved output\n===============\n\nOur previous Azure Pipelines-based CI builds had a much nicer UI, one that\neven showed flaky tests, and trends e.g. how long the test cases ran. When I\nported Git's CI over to GitHub workflows (to make CI more accessible to new\ncontributors), I knew fully well that we would leave this very nice UI\nbehind, and I had hoped that we would get something similar back via new,\ncommunity-contributed GitHub Actions that can be used in GitHub workflows.\nHowever, most likely because we use a home-grown test framework implemented\nin opinionated POSIX shells scripts, that did not happen.\n\nSo I had a look at what standards exist e.g. when testing PowerShell\nmodules, in the way of marking up their test output in GitHub workflows, and\nI was not disappointed: GitHub workflows support \"grouping\" of output lines,\ni.e. marking sections of the output as a group that is then collapsed by\ndefault and can be expanded. And it is this feature I decided to use in this\npatch series, along with GitHub workflows' commands to display errors or\nnotices that are also shown on the summary page of the workflow run. Now, in\naddition to \"Process completed with exit code\" on the summary page, we also\nread something like:\n\n⊗ linux-gcc (ubuntu-latest)\n   failed: t9800.20 submit from detached head\n\n\nEven better, this message is a link, and following that, the reader is\npresented with something like this\n[https://github.com/dscho/git/runs/4840190622?check_suite_focus=true]:\n\n⏵ Run ci/run-build-and-tests.sh\n⏵ CI setup\n  + ln -s /home/runner/none/.prove t/.prove\n  + run_tests=t\n  + export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n  + group Build make\n  + set +x\n⏵ Build\n⏵ Run tests\n  === Failed test: t9800-git-p4-basic ===\n⏵ ok: t9800.1 start p4d\n⏵ ok: t9800.2 add p4 files\n⏵ ok: t9800.3 basic git p4 clone\n⏵ ok: t9800.4 depot typo error\n⏵ ok: t9800.5 git p4 clone @all\n⏵ ok: t9800.6 git p4 sync uninitialized repo\n⏵ ok: t9800.7 git p4 sync new branch\n⏵ ok: t9800.8 clone two dirs\n⏵ ok: t9800.9 clone two dirs, @all\n⏵ ok: t9800.10 clone two dirs, @all, conflicting files\n⏵ ok: t9800.11 clone two dirs, each edited by submit, single git commit\n⏵ ok: t9800.12 clone using non-numeric revision ranges\n⏵ ok: t9800.13 clone with date range, excluding some changes\n⏵ ok: t9800.14 exit when p4 fails to produce marshaled output\n⏵ ok: t9800.15 exit gracefully for p4 server errors\n⏵ ok: t9800.16 clone --bare should make a bare repository\n⏵ ok: t9800.17 initial import time from top change time\n⏵ ok: t9800.18 unresolvable host in P4PORT should display error\n⏵ ok: t9800.19 run hook p4-pre-submit before submit\n  Error: failed: t9800.20 submit from detached head\n⏵ failure: t9800.20 submit from detached head \n  Error: failed: t9800.21 submit from worktree\n⏵ failure: t9800.21 submit from worktree \n  === Failed test: t9801-git-p4-branch ===\n  [...]\n\n\nThe \"Failed test:\" lines are colored in yellow to give a better visual clue\nabout the logs' structure, the \"Error:\" label is colored in red to draw the\nattention to the important part of the log, and the \"⏵\" characters indicate\nthat part of the log is collapsed and can be expanded by clicking on it.\n\nTo drill down, the reader merely needs to expand the (failed) test case's\nlog by clicking on it, and then study the log. If needed (e.g. when the test\ncase relies on side effects from previous test cases), the logs of preceding\ntest cases can be expanded as well. In this example, when expanding\nt9800.20, it looks like this (for ease of reading, I cut a few chunks of\nlines, indicated by \"[...]\"):\n\n[...]\n⏵ ok: t9800.19 run hook p4-pre-submit before submit\n  Error: failed: t9800.20 submit from detached head\n⏷ failure: t9800.20 submit from detached head \n      test_when_finished cleanup_git &&\n      git p4 clone --dest=\"$git\" //depot &&\n        (\n          cd \"$git\" &&\n          git checkout p4/master &&\n          >detached_head_test &&\n          git add detached_head_test &&\n          git commit -m \"add detached_head\" &&\n          git config git-p4.skipSubmitEdit true &&\n          git p4 submit &&\n            git p4 rebase &&\n            git log p4/master | grep detached_head\n        )\n    [...]\n    Depot paths: //depot/\n    Import destination: refs/remotes/p4/master\n    \n    Importing revision 9 (100%)Perforce db files in '.' will be created if missing...\n    Perforce db files in '.' will be created if missing...\n    \n    Traceback (most recent call last):\n      File \"/home/runner/work/git/git/git-p4\", line 4455, in <module>\n        main()\n      File \"/home/runner/work/git/git/git-p4\", line 4449, in main\n        if not cmd.run(args):\n      File \"/home/runner/work/git/git/git-p4\", line 2590, in run\n        rebase.rebase()\n      File \"/home/runner/work/git/git/git-p4\", line 4121, in rebase\n        if len(read_pipe(\"git diff-index HEAD --\")) > 0:\n      File \"/home/runner/work/git/git/git-p4\", line 297, in read_pipe\n        retcode, out, err = read_pipe_full(c, *k, **kw)\n      File \"/home/runner/work/git/git/git-p4\", line 284, in read_pipe_full\n        p = subprocess.Popen(\n      File \"/usr/lib/python3.8/subprocess.py\", line 858, in __init__\n        self._execute_child(args, executable, preexec_fn, close_fds,\n      File \"/usr/lib/python3.8/subprocess.py\", line 1704, in _execute_child\n        raise child_exception_type(errno_num, err_msg, err_filename)\n    FileNotFoundError: [Errno 2] No such file or directory: 'git diff-index HEAD --'\n    error: last command exited with $?=1\n    + cleanup_git\n    + retry_until_success rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + nr_tries_left=60\n    + rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + test_path_is_missing /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + test 1 -ne 1\n    + test -e /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + retry_until_success mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + nr_tries_left=60\n    + mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n    + exit 1\n    + eval_ret=1\n    + :\n    not ok 20 - submit from detached head\n    #    \n    #        test_when_finished cleanup_git &&\n    #        git p4 clone --dest=\"$git\" //depot &&\n    #        (\n    #            cd \"$git\" &&\n    #            git checkout p4/master &&\n    #            >detached_head_test &&\n    #            git add detached_head_test &&\n    #            git commit -m \"add detached_head\" &&\n    #            git config git-p4.skipSubmitEdit true &&\n    #            git p4 submit &&\n    #            git p4 rebase &&\n    #            git log p4/master | grep detached_head\n    #        )\n    #    \n  Error: failed: t9800.21 submit from worktree\n  [...]\n\n\nIs this the best UI we can have for test failures in CI runs? I hope we can\ndo better. Having said that, this patch series presents a pretty good start,\nand offers a basis for future improvements.\n\nJohannes Schindelin (9):\n  ci: fix code style\n  ci/run-build-and-tests: take a more high-level view\n  ci: make it easier to find failed tests' logs in the GitHub workflow\n  ci/run-build-and-tests: add some structure to the GitHub workflow\n    output\n  tests: refactor --write-junit-xml code\n  test(junit): avoid line feeds in XML attributes\n  ci: optionally mark up output in the GitHub workflow\n  ci: use `--github-workflow-markup` in the GitHub workflow\n  ci: call `finalize_test_case_output` a little later\n\n .github/workflows/main.yml           |  12 ---\n ci/lib.sh                            |  82 +++++++++++++++--\n ci/run-build-and-tests.sh            |  14 +--\n ci/run-test-slice.sh                 |   5 +-\n t/test-lib-functions.sh              |   4 +-\n t/test-lib-github-workflow-markup.sh |  50 ++++++++++\n t/test-lib-junit.sh                  | 132 +++++++++++++++++++++++++++\n t/test-lib.sh                        | 128 ++++----------------------\n 8 files changed, 288 insertions(+), 139 deletions(-)\n create mode 100644 t/test-lib-github-workflow-markup.sh\n create mode 100644 t/test-lib-junit.sh\n\n\nbase-commit: af4e5f569bc89f356eb34a9373d7f82aca6faa8a\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1117%2Fdscho%2Fuse-grouping-in-ci-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1117/dscho/use-grouping-in-ci-v2\nPull-Request: https://github.com/gitgitgadget/git/pull/1117\n\nRange-diff vs v1:\n\n  1:  db08b07c37a =  1:  db08b07c37a ci: fix code style\n  2:  d2ff51bb5da !  2:  42ff3e170bf ci/run-build-and-tests: take a more high-level view\n     @@ ci/run-build-and-tests.sh: pedantic)\n       \t;;\n       esac\n       \n     - # Any new \"test\" targets should not go after this \"make\", but should\n     - # adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n     - # start running tests.\n     +-# Any new \"test\" targets should not go after this \"make\", but should\n     +-# adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n     +-# start running tests.\n      -make $MAKE_TARGETS\n      +make\n      +if test -n \"$run_tests\"\n  3:  98891b0d3f7 !  3:  bbbe1623257 ci: make it easier to find failed tests' logs in the GitHub workflow\n     @@ Metadata\n       ## Commit message ##\n          ci: make it easier to find failed tests' logs in the GitHub workflow\n      \n     +    When investigating a test failure, the time that matters most is the\n     +    time it takes from getting aware of the failure to displaying the output\n     +    of the failing test case.\n     +\n          You currently have to know a lot of implementation details when\n          investigating test failures in the CI runs. The first step is easy: the\n          failed job is marked quite clearly, but when opening it, the failed step\n     @@ Commit message\n          The actually interesting part is in the detailed log of said failed\n          test script. But that log is shown in the CI run's step that runs\n          `ci/print-test-failures.sh`. And that step is _not_ expanded in the web\n     -    UI by default.\n     +    UI by default. It is even marked as \"successful\", which makes it very\n     +    easy to miss that there is useful information hidden in there.\n      \n          Let's help the reader by showing the failed tests' detailed logs in the\n          step that is expanded automatically, i.e. directly after the test suite\n  4:  9333ba781b8 !  4:  f72254a9ac6 ci/run-build-and-tests: add some structure to the GitHub workflow output\n     @@ ci/lib.sh\n      +\n      +# Set 'exit on error' for all CI scripts to let the caller know that\n      +# something went wrong.\n     -+# Set tracing executed commands, primarily setting environment variables\n     -+# and installing dependencies.\n     ++#\n     ++# We already enabled tracing executed commands earlier. This helps by showing\n     ++# how # environment variables are set and and dependencies are installed.\n      +set -e\n      +\n       skip_branch_tip_with_tag () {\n     @@ ci/lib.sh: linux-leaks)\n      +set -x\n      \n       ## ci/run-build-and-tests.sh ##\n     -@@ ci/run-build-and-tests.sh: esac\n     - # Any new \"test\" targets should not go after this \"make\", but should\n     - # adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n     - # start running tests.\n     +@@ ci/run-build-and-tests.sh: pedantic)\n     + \t;;\n     + esac\n     + \n      -make\n      +group Build make\n       if test -n \"$run_tests\"\n  5:  94dcbe1bc43 =  5:  9eda6574313 tests: refactor --write-junit-xml code\n  6:  41230100091 =  6:  c8b240af749 test(junit): avoid line feeds in XML attributes\n  7:  98b32630fcd =  7:  15f199e810e ci: optionally mark up output in the GitHub workflow\n  8:  1a6bd1846bc =  8:  91ea54f36c5 ci: use `--github-workflow-markup` in the GitHub workflow\n  9:  992b1575889 =  9:  be2a83f5da3 ci: call `finalize_test_case_output` a little later\n\n-- \ngitgitgadget\n"},{"id":"449909","messageId":"db08b07c37a81866c63b062c92d9ee78976d1b34.1646130289.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"[PATCH v2 1/9] ci: fix code style","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-03-01T10:24:41Z","receivedAt":"2022-03-01T10:25:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nIn b92cb86ea14 (travis-ci: check that all build artifacts are\n.gitignore-d, 2017-12-31), a function was introduced with a code style\nthat is different from the surrounding code: it added the opening curly\nbrace on its own line, when all the existing functions in the same file\ncuddle that brace on the same line as the function name.\n\nLet's make the code style consistent again.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/lib.sh | 3 +--\n 1 file changed, 1 insertion(+), 2 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 9d28ab50fb4..ebb502640fa 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -69,8 +69,7 @@ skip_good_tree () {\n \texit 0\n }\n \n-check_unignored_build_artifacts ()\n-{\n+check_unignored_build_artifacts () {\n \t! git ls-files --other --exclude-standard --error-unmatch \\\n \t\t-- ':/*' 2>/dev/null ||\n \t{\n-- \ngitgitgadget\n\n"},{"id":"449910","messageId":"42ff3e170bff42f9b9ca6adb433b3d7c2a39c729.1646130289.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"[PATCH v2 2/9] ci/run-build-and-tests: take a more high-level view","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-03-01T10:24:42Z","receivedAt":"2022-03-01T10:25:02Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nIn the web UI of GitHub workflows, failed runs are presented with the\njob step that failed auto-expanded. In the current setup, this is not\nhelpful at all because that shows only the output of `prove`, which says\nwhich test failed, but not in what way.\n\nWhat would help understand the reader what went wrong is the verbose\ntest output of the failed test.\n\nThe logs of the failed runs do contain that verbose test output, but it\nis shown in the _next_ step (which is marked as succeeding, and is\ntherefore _not_ auto-expanded). Anyone not intimately familiar with this\nwould completely miss the verbose test output, being left mostly\npuzzled with the test failures.\n\nWe are about to show the failed test cases' output in the _same_ step,\nso that the user has a much easier time to figure out what was going\nwrong.\n\nBut first, we must partially revert the change that tried to improve the\nCI runs by combining the `Makefile` targets to build into a single\n`make` invocation. That might have sounded like a good idea at the time,\nbut it does make it rather impossible for the CI script to determine\nwhether the _build_ failed, or the _tests_. If the tests were run at\nall, that is.\n\nSo let's go back to calling `make` for the build, and call `make test`\nseparately so that we can easily detect that _that_ invocation failed,\nand react appropriately.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/run-build-and-tests.sh | 13 +++++++------\n 1 file changed, 7 insertions(+), 6 deletions(-)\n\ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex 280dda7d285..2818b3046ae 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -10,7 +10,7 @@ windows*) cmd //c mklink //j t\\\\.prove \"$(cygpath -aw \"$cache_dir/.prove\")\";;\n *) ln -s \"$cache_dir/.prove\" t/.prove;;\n esac\n \n-export MAKE_TARGETS=\"all test\"\n+run_tests=t\n \n case \"$jobname\" in\n linux-gcc)\n@@ -41,14 +41,15 @@ pedantic)\n \t# Don't run the tests; we only care about whether Git can be\n \t# built.\n \texport DEVOPTS=pedantic\n-\texport MAKE_TARGETS=all\n+\trun_tests=\n \t;;\n esac\n \n-# Any new \"test\" targets should not go after this \"make\", but should\n-# adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n-# start running tests.\n-make $MAKE_TARGETS\n+make\n+if test -n \"$run_tests\"\n+then\n+\tmake test\n+fi\n check_unignored_build_artifacts\n \n save_good_tree\n-- \ngitgitgadget\n\n"},{"id":"449911","messageId":"bbbe1623257bd396d8910915fbfc364433125021.1646130289.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"[PATCH v2 3/9] ci: make it easier to find failed tests' logs in the GitHub workflow","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-03-01T10:24:43Z","receivedAt":"2022-03-01T10:25:04Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nWhen investigating a test failure, the time that matters most is the\ntime it takes from getting aware of the failure to displaying the output\nof the failing test case.\n\nYou currently have to know a lot of implementation details when\ninvestigating test failures in the CI runs. The first step is easy: the\nfailed job is marked quite clearly, but when opening it, the failed step\nis expanded, which in our case is the one running\n`ci/run-build-and-tests.sh`. This step, most notably, only offers a\nhigh-level view of what went wrong: it prints the output of `prove`\nwhich merely tells the reader which test script failed.\n\nThe actually interesting part is in the detailed log of said failed\ntest script. But that log is shown in the CI run's step that runs\n`ci/print-test-failures.sh`. And that step is _not_ expanded in the web\nUI by default. It is even marked as \"successful\", which makes it very\neasy to miss that there is useful information hidden in there.\n\nLet's help the reader by showing the failed tests' detailed logs in the\nstep that is expanded automatically, i.e. directly after the test suite\nfailed.\n\nThis also helps the situation where the _build_ failed and the\n`print-test-failures` step was executed under the assumption that the\n_test suite_ failed, and consequently failed to find any failed tests.\n\nAn alternative way to implement this patch would be to source\n`ci/print-test-failures.sh` in the `handle_test_failures` function to\nshow these logs. However, over the course of the next few commits, we\nwant to introduce some grouping which would be harder to achieve that\nway (for example, we do want a leaner, and colored, preamble for each\nfailed test script, and it would be trickier to accommodate the lack of\nnested groupings in GitHub workflows' output).\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n .github/workflows/main.yml | 12 ------------\n ci/lib.sh                  | 23 +++++++++++++++++++++++\n ci/run-build-and-tests.sh  |  3 ++-\n ci/run-test-slice.sh       |  3 ++-\n 4 files changed, 27 insertions(+), 14 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex c35200defb9..3fa88b78b6d 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -119,10 +119,6 @@ jobs:\n     - name: test\n       shell: bash\n       run: . /etc/profile && ci/run-test-slice.sh ${{matrix.nr}} 10\n-    - name: ci/print-test-failures.sh\n-      if: failure()\n-      shell: bash\n-      run: ci/print-test-failures.sh\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v2\n@@ -204,10 +200,6 @@ jobs:\n       env:\n         NO_SVN_TESTS: 1\n       run: . /etc/profile && ci/run-test-slice.sh ${{matrix.nr}} 10\n-    - name: ci/print-test-failures.sh\n-      if: failure()\n-      shell: bash\n-      run: ci/print-test-failures.sh\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v2\n@@ -261,8 +253,6 @@ jobs:\n     - uses: actions/checkout@v2\n     - run: ci/install-dependencies.sh\n     - run: ci/run-build-and-tests.sh\n-    - run: ci/print-test-failures.sh\n-      if: failure()\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v2\n@@ -292,8 +282,6 @@ jobs:\n     - uses: actions/checkout@v1\n     - run: ci/install-docker-dependencies.sh\n     - run: ci/run-build-and-tests.sh\n-    - run: ci/print-test-failures.sh\n-      if: failure()\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v1\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex ebb502640fa..2b2c0932320 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -78,6 +78,10 @@ check_unignored_build_artifacts () {\n \t}\n }\n \n+handle_failed_tests () {\n+\treturn 1\n+}\n+\n # GitHub Action doesn't set TERM, which is required by tput\n export TERM=${TERM:-dumb}\n \n@@ -123,6 +127,25 @@ then\n \tCI_JOB_ID=\"$GITHUB_RUN_ID\"\n \tCC=\"${CC:-gcc}\"\n \tDONT_SKIP_TAGS=t\n+\thandle_failed_tests () {\n+\t\tmkdir -p t/failed-test-artifacts\n+\t\techo \"FAILED_TEST_ARTIFACTS=t/failed-test-artifacts\" >>$GITHUB_ENV\n+\n+\t\tfor test_exit in t/test-results/*.exit\n+\t\tdo\n+\t\t\ttest 0 != \"$(cat \"$test_exit\")\" || continue\n+\n+\t\t\ttest_name=\"${test_exit%.exit}\"\n+\t\t\ttest_name=\"${test_name##*/}\"\n+\t\t\tprintf \"\\\\e[33m\\\\e[1m=== Failed test: ${test_name} ===\\\\e[m\\\\n\"\n+\t\t\tcat \"t/test-results/$test_name.out\"\n+\n+\t\t\ttrash_dir=\"t/trash directory.$test_name\"\n+\t\t\tcp \"t/test-results/$test_name.out\" t/failed-test-artifacts/\n+\t\t\ttar czf t/failed-test-artifacts/\"$test_name\".trash.tar.gz \"$trash_dir\"\n+\t\tdone\n+\t\treturn 1\n+\t}\n \n \tcache_dir=\"$HOME/none\"\n \ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex 2818b3046ae..1ede75e5556 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -48,7 +48,8 @@ esac\n make\n if test -n \"$run_tests\"\n then\n-\tmake test\n+\tmake test ||\n+\thandle_failed_tests\n fi\n check_unignored_build_artifacts\n \ndiff --git a/ci/run-test-slice.sh b/ci/run-test-slice.sh\nindex f8c2c3106a2..63358c23e11 100755\n--- a/ci/run-test-slice.sh\n+++ b/ci/run-test-slice.sh\n@@ -12,6 +12,7 @@ esac\n \n make --quiet -C t T=\"$(cd t &&\n \t./helper/test-tool path-utils slice-tests \"$1\" \"$2\" t[0-9]*.sh |\n-\ttr '\\n' ' ')\"\n+\ttr '\\n' ' ')\" ||\n+handle_failed_tests\n \n check_unignored_build_artifacts\n-- \ngitgitgadget\n\n"},{"id":"449912","messageId":"f72254a9ac6ef90f222d64c8c9a08e79ee4544c7.1646130289.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"[PATCH v2 4/9] ci/run-build-and-tests: add some structure to the GitHub workflow output","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-03-01T10:24:44Z","receivedAt":"2022-03-01T10:25:08Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nThe current output of Git's GitHub workflow can be quite confusing,\nespecially for contributors new to the project.\n\nTo make it more helpful, let's introduce some collapsible grouping.\nInitially, readers will see the high-level view of what actually\nhappened (did the build fail, or the test suite?). To drill down, the\nrespective group can be expanded.\n\nNote: sadly, workflow output currently cannot contain any nested groups\n(see https://github.com/actions/runner/issues/802 for details),\ntherefore we take pains to ensure to end any previous group before\nstarting a new one.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/lib.sh                 | 56 ++++++++++++++++++++++++++++++++++-----\n ci/run-build-and-tests.sh |  4 +--\n ci/run-test-slice.sh      |  2 +-\n 3 files changed, 52 insertions(+), 10 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 2b2c0932320..2a1b22db12a 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -1,5 +1,50 @@\n # Library of functions shared by all CI scripts\n \n+if test true != \"$GITHUB_ACTIONS\"\n+then\n+\tbegin_group () { :; }\n+\tend_group () { :; }\n+\n+\tgroup () {\n+\t\tshift\n+\t\t\"$@\"\n+\t}\n+\tset -x\n+else\n+\tbegin_group () {\n+\t\tneed_to_end_group=t\n+\t\techo \"::group::$1\" >&2\n+\t\tset -x\n+\t}\n+\n+\tend_group () {\n+\t\ttest -n \"$need_to_end_group\" || return 0\n+\t\tset +x\n+\t\tneed_to_end_group=\n+\t\techo '::endgroup::' >&2\n+\t}\n+\ttrap end_group EXIT\n+\n+\tgroup () {\n+\t\tset +x\n+\t\tbegin_group \"$1\"\n+\t\tshift\n+\t\t\"$@\"\n+\t\tres=$?\n+\t\tend_group\n+\t\treturn $res\n+\t}\n+\n+\tbegin_group \"CI setup\"\n+fi\n+\n+# Set 'exit on error' for all CI scripts to let the caller know that\n+# something went wrong.\n+#\n+# We already enabled tracing executed commands earlier. This helps by showing\n+# how # environment variables are set and and dependencies are installed.\n+set -e\n+\n skip_branch_tip_with_tag () {\n \t# Sometimes, a branch is pushed at the same time the tag that points\n \t# at the same commit as the tip of the branch is pushed, and building\n@@ -88,12 +133,6 @@ export TERM=${TERM:-dumb}\n # Clear MAKEFLAGS that may come from the outside world.\n export MAKEFLAGS=\n \n-# Set 'exit on error' for all CI scripts to let the caller know that\n-# something went wrong.\n-# Set tracing executed commands, primarily setting environment variables\n-# and installing dependencies.\n-set -ex\n-\n if test -n \"$SYSTEM_COLLECTIONURI\" || test -n \"$SYSTEM_TASKDEFINITIONSURI\"\n then\n \tCI_TYPE=azure-pipelines\n@@ -138,7 +177,7 @@ then\n \t\t\ttest_name=\"${test_exit%.exit}\"\n \t\t\ttest_name=\"${test_name##*/}\"\n \t\t\tprintf \"\\\\e[33m\\\\e[1m=== Failed test: ${test_name} ===\\\\e[m\\\\n\"\n-\t\t\tcat \"t/test-results/$test_name.out\"\n+\t\t\tgroup \"Failed test: $test_name\" cat \"t/test-results/$test_name.out\"\n \n \t\t\ttrash_dir=\"t/trash directory.$test_name\"\n \t\t\tcp \"t/test-results/$test_name.out\" t/failed-test-artifacts/\n@@ -234,3 +273,6 @@ linux-leaks)\n esac\n \n MAKEFLAGS=\"$MAKEFLAGS CC=${CC:-cc}\"\n+\n+end_group\n+set -x\ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex 1ede75e5556..7abfa00adc0 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -45,10 +45,10 @@ pedantic)\n \t;;\n esac\n \n-make\n+group Build make\n if test -n \"$run_tests\"\n then\n-\tmake test ||\n+\tgroup \"Run tests\" make test ||\n \thandle_failed_tests\n fi\n check_unignored_build_artifacts\ndiff --git a/ci/run-test-slice.sh b/ci/run-test-slice.sh\nindex 63358c23e11..a3c67956a8d 100755\n--- a/ci/run-test-slice.sh\n+++ b/ci/run-test-slice.sh\n@@ -10,7 +10,7 @@ windows*) cmd //c mklink //j t\\\\.prove \"$(cygpath -aw \"$cache_dir/.prove\")\";;\n *) ln -s \"$cache_dir/.prove\" t/.prove;;\n esac\n \n-make --quiet -C t T=\"$(cd t &&\n+group \"Run tests\" make --quiet -C t T=\"$(cd t &&\n \t./helper/test-tool path-utils slice-tests \"$1\" \"$2\" t[0-9]*.sh |\n \ttr '\\n' ' ')\" ||\n handle_failed_tests\n-- \ngitgitgadget\n\n"},{"id":"449913","messageId":"9eda6574313c7316d7f72e06d642bfbe6edd4492.1646130289.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"[PATCH v2 5/9] tests: refactor --write-junit-xml code","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-03-01T10:24:45Z","receivedAt":"2022-03-01T10:25:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nThe code writing JUnit XML is interspersed directly with all the code in\n`t/test-lib.sh`, and it is therefore not only ill-separated, but\nintroducing yet another output format would make the situation even\nworse.\n\nLet's introduce an abstraction layer by hiding the JUnit XML code behind\nfour new functions that are supposed to be called before and after each\ntest and test case.\n\nThis is not just an academic exercise, refactoring for refactoring's\nsake. We _actually_ want to introduce such a new output format, to\nmake it substantially easier to diagnose test failures in our GitHub\nworkflow, therefore we do need this refactoring.\n\nThis commit is best viewed with `git show --color-moved\n--color-moved-ws=allow-indentation-change <commit>`.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib-junit.sh | 126 ++++++++++++++++++++++++++++++++++++++++++++\n t/test-lib.sh       | 124 ++++++-------------------------------------\n 2 files changed, 142 insertions(+), 108 deletions(-)\n create mode 100644 t/test-lib-junit.sh\n\ndiff --git a/t/test-lib-junit.sh b/t/test-lib-junit.sh\nnew file mode 100644\nindex 00000000000..9d55d74d764\n--- /dev/null\n+++ b/t/test-lib-junit.sh\n@@ -0,0 +1,126 @@\n+# Library of functions to format test scripts' output in JUnit XML\n+# format, to support Git's test suite result to be presented in an\n+# easily digestible way on Azure Pipelines.\n+#\n+# Copyright (c) 2022 Johannes Schindelin\n+#\n+# This program is free software: you can redistribute it and/or modify\n+# it under the terms of the GNU General Public License as published by\n+# the Free Software Foundation, either version 2 of the License, or\n+# (at your option) any later version.\n+#\n+# This program is distributed in the hope that it will be useful,\n+# but WITHOUT ANY WARRANTY; without even the implied warranty of\n+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n+# GNU General Public License for more details.\n+#\n+# You should have received a copy of the GNU General Public License\n+# along with this program.  If not, see http://www.gnu.org/licenses/ .\n+#\n+# The idea is for `test-lib.sh` to source this file when the user asks\n+# for JUnit XML; these functions will then override (empty) functions\n+# that are are called at the appropriate times during the test runs.\n+\n+start_test_output () {\n+\tjunit_xml_dir=\"$TEST_OUTPUT_DIRECTORY/out\"\n+\tmkdir -p \"$junit_xml_dir\"\n+\tjunit_xml_base=${1##*/}\n+\tjunit_xml_path=\"$junit_xml_dir/TEST-${junit_xml_base%.sh}.xml\"\n+\tjunit_attrs=\"name=\\\"${junit_xml_base%.sh}\\\"\"\n+\tjunit_attrs=\"$junit_attrs timestamp=\\\"$(TZ=UTC \\\n+\t\tdate +%Y-%m-%dT%H:%M:%S)\\\"\"\n+\twrite_junit_xml --truncate \"<testsuites>\" \"  <testsuite $junit_attrs>\"\n+\tjunit_suite_start=$(test-tool date getnanos)\n+\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n+\tthen\n+\t\tGIT_TEST_TEE_OFFSET=0\n+\tfi\n+}\n+\n+start_test_case_output () {\n+\tjunit_start=$(test-tool date getnanos)\n+}\n+\n+finalize_test_case_output () {\n+\ttest_case_result=$1\n+\tshift\n+\tcase \"$test_case_result\" in\n+\tok)\n+\t\tset \"$*\"\n+\t\t;;\n+\tfailure)\n+\t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n+\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \"$1\")\\\">\"\n+\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \\\n+\t\t\t\"$(if test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n+\t\t\t   then\n+\t\t\t\ttest-tool path-utils skip-n-bytes \\\n+\t\t\t\t\t\"$GIT_TEST_TEE_OUTPUT_FILE\" $GIT_TEST_TEE_OFFSET\n+\t\t\t   else\n+\t\t\t\tprintf '%s\\n' \"$@\" | sed 1d\n+\t\t\t   fi)\")\"\n+\t\tjunit_insert=\"$junit_insert</failure>\"\n+\t\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n+\t\tthen\n+\t\t\tjunit_insert=\"$junit_insert<system-err>$(xml_attr_encode \\\n+\t\t\t\t\"$(cat \"$GIT_TEST_TEE_OUTPUT_FILE\")\")</system-err>\"\n+\t\tfi\n+\t\tset \"$1\" \"      $junit_insert\"\n+\t\t;;\n+\tfixed)\n+\t\tset \"$* (breakage fixed)\"\n+\t\t;;\n+\tbroken)\n+\t\tset \"$* (known breakage)\"\n+\t\t;;\n+\tskip)\n+\t\tmessage=\"$(xml_attr_encode \"$skipped_reason\")\"\n+\t\tset \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n+\t\t;;\n+\tesac\n+\n+\tjunit_attrs=\"name=\\\"$(xml_attr_encode \"$this_test.$test_count $1\")\\\"\"\n+\tshift\n+\tjunit_attrs=\"$junit_attrs classname=\\\"$this_test\\\"\"\n+\tjunit_attrs=\"$junit_attrs time=\\\"$(test-tool \\\n+\t\tdate getnanos $junit_start)\\\"\"\n+\twrite_junit_xml \"$(printf '%s\\n' \\\n+\t\t\"    <testcase $junit_attrs>\" \"$@\" \"    </testcase>\")\"\n+\tjunit_have_testcase=t\n+}\n+\n+finalize_test_output () {\n+\tif test -n \"$junit_xml_path\"\n+\tthen\n+\t\ttest -n \"$junit_have_testcase\" || {\n+\t\t\tjunit_start=$(test-tool date getnanos)\n+\t\t\twrite_junit_xml_testcase \"all tests skipped\"\n+\t\t}\n+\n+\t\t# adjust the overall time\n+\t\tjunit_time=$(test-tool date getnanos $junit_suite_start)\n+\t\tsed -e \"s/\\(<testsuite.*\\) time=\\\"[^\\\"]*\\\"/\\1/\" \\\n+\t\t\t-e \"s/<testsuite [^>]*/& time=\\\"$junit_time\\\"/\" \\\n+\t\t\t-e '/^ *<\\/testsuite/d' \\\n+\t\t\t<\"$junit_xml_path\" >\"$junit_xml_path.new\"\n+\t\tmv \"$junit_xml_path.new\" \"$junit_xml_path\"\n+\n+\t\twrite_junit_xml \"  </testsuite>\" \"</testsuites>\"\n+\t\twrite_junit_xml=\n+\tfi\n+}\n+\n+write_junit_xml () {\n+\tcase \"$1\" in\n+\t--truncate)\n+\t\t>\"$junit_xml_path\"\n+\t\tjunit_have_testcase=\n+\t\tshift\n+\t\t;;\n+\tesac\n+\tprintf '%s\\n' \"$@\" >>\"$junit_xml_path\"\n+}\n+\n+xml_attr_encode () {\n+\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n+}\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 0f7a137c7d8..e13e1cb9124 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -107,6 +107,12 @@ mark_option_requires_arg () {\n \tstore_arg_to=$2\n }\n \n+# These functions can be overridden e.g. to output JUnit XML\n+start_test_output () { :; }\n+start_test_case_output () { :; }\n+finalize_test_case_output () { :; }\n+finalize_test_output () { :; }\n+\n parse_option () {\n \tlocal opt=\"$1\"\n \n@@ -166,7 +172,7 @@ parse_option () {\n \t\ttee=t\n \t\t;;\n \t--write-junit-xml)\n-\t\twrite_junit_xml=t\n+\t\t. \"$TEST_DIRECTORY/test-lib-junit.sh\"\n \t\t;;\n \t--stress)\n \t\tstress=t ;;\n@@ -613,7 +619,7 @@ exec 6<&0\n exec 7>&2\n \n _error_exit () {\n-\tfinalize_junit_xml\n+\tfinalize_test_output\n \tGIT_EXIT_OK=t\n \texit 1\n }\n@@ -723,35 +729,13 @@ trap '{ code=$?; set +x; } 2>/dev/null; exit $code' INT TERM HUP\n # the test_expect_* functions instead.\n \n test_ok_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\twrite_junit_xml_testcase \"$*\"\n-\tfi\n+\tfinalize_test_case_output ok \"$@\"\n \ttest_success=$(($test_success + 1))\n \tsay_color \"\" \"ok $test_count - $@\"\n }\n \n test_failure_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n-\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \"$1\")\\\">\"\n-\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \\\n-\t\t\t\"$(if test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n-\t\t\t   then\n-\t\t\t\ttest-tool path-utils skip-n-bytes \\\n-\t\t\t\t\t\"$GIT_TEST_TEE_OUTPUT_FILE\" $GIT_TEST_TEE_OFFSET\n-\t\t\t   else\n-\t\t\t\tprintf '%s\\n' \"$@\" | sed 1d\n-\t\t\t   fi)\")\"\n-\t\tjunit_insert=\"$junit_insert</failure>\"\n-\t\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n-\t\tthen\n-\t\t\tjunit_insert=\"$junit_insert<system-err>$(xml_attr_encode \\\n-\t\t\t\t\"$(cat \"$GIT_TEST_TEE_OUTPUT_FILE\")\")</system-err>\"\n-\t\tfi\n-\t\twrite_junit_xml_testcase \"$1\" \"      $junit_insert\"\n-\tfi\n+\tfinalize_test_case_output failure \"$@\"\n \ttest_failure=$(($test_failure + 1))\n \tsay_color error \"not ok $test_count - $1\"\n \tshift\n@@ -760,19 +744,13 @@ test_failure_ () {\n }\n \n test_known_broken_ok_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\twrite_junit_xml_testcase \"$* (breakage fixed)\"\n-\tfi\n+\tfinalize_test_case_output fixed \"$@\"\n \ttest_fixed=$(($test_fixed+1))\n \tsay_color error \"ok $test_count - $@ # TODO known breakage vanished\"\n }\n \n test_known_broken_failure_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\twrite_junit_xml_testcase \"$* (known breakage)\"\n-\tfi\n+\tfinalize_test_case_output broken \"$@\"\n \ttest_broken=$(($test_broken+1))\n \tsay_color warn \"not ok $test_count - $@ # TODO known breakage\"\n }\n@@ -1049,10 +1027,7 @@ test_start_ () {\n \ttest_count=$(($test_count+1))\n \tmaybe_setup_verbose\n \tmaybe_setup_valgrind\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\tjunit_start=$(test-tool date getnanos)\n-\tfi\n+\tstart_test_case_output\n }\n \n test_finish_ () {\n@@ -1103,12 +1078,7 @@ test_skip () {\n \n \tcase \"$to_skip\" in\n \tt)\n-\t\tif test -n \"$write_junit_xml\"\n-\t\tthen\n-\t\t\tmessage=\"$(xml_attr_encode \"$skipped_reason\")\"\n-\t\t\twrite_junit_xml_testcase \"$1\" \\\n-\t\t\t\t\"      <skipped message=\\\"$message\\\" />\"\n-\t\tfi\n+\t\tfinalize_test_case_output skip \"$@\"\n \n \t\tsay_color skip \"ok $test_count # skip $1 ($skipped_reason)\"\n \t\t: true\n@@ -1124,53 +1094,6 @@ test_at_end_hook_ () {\n \t:\n }\n \n-write_junit_xml () {\n-\tcase \"$1\" in\n-\t--truncate)\n-\t\t>\"$junit_xml_path\"\n-\t\tjunit_have_testcase=\n-\t\tshift\n-\t\t;;\n-\tesac\n-\tprintf '%s\\n' \"$@\" >>\"$junit_xml_path\"\n-}\n-\n-xml_attr_encode () {\n-\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n-}\n-\n-write_junit_xml_testcase () {\n-\tjunit_attrs=\"name=\\\"$(xml_attr_encode \"$this_test.$test_count $1\")\\\"\"\n-\tshift\n-\tjunit_attrs=\"$junit_attrs classname=\\\"$this_test\\\"\"\n-\tjunit_attrs=\"$junit_attrs time=\\\"$(test-tool \\\n-\t\tdate getnanos $junit_start)\\\"\"\n-\twrite_junit_xml \"$(printf '%s\\n' \\\n-\t\t\"    <testcase $junit_attrs>\" \"$@\" \"    </testcase>\")\"\n-\tjunit_have_testcase=t\n-}\n-\n-finalize_junit_xml () {\n-\tif test -n \"$write_junit_xml\" && test -n \"$junit_xml_path\"\n-\tthen\n-\t\ttest -n \"$junit_have_testcase\" || {\n-\t\t\tjunit_start=$(test-tool date getnanos)\n-\t\t\twrite_junit_xml_testcase \"all tests skipped\"\n-\t\t}\n-\n-\t\t# adjust the overall time\n-\t\tjunit_time=$(test-tool date getnanos $junit_suite_start)\n-\t\tsed -e \"s/\\(<testsuite.*\\) time=\\\"[^\\\"]*\\\"/\\1/\" \\\n-\t\t\t-e \"s/<testsuite [^>]*/& time=\\\"$junit_time\\\"/\" \\\n-\t\t\t-e '/^ *<\\/testsuite/d' \\\n-\t\t\t<\"$junit_xml_path\" >\"$junit_xml_path.new\"\n-\t\tmv \"$junit_xml_path.new\" \"$junit_xml_path\"\n-\n-\t\twrite_junit_xml \"  </testsuite>\" \"</testsuites>\"\n-\t\twrite_junit_xml=\n-\tfi\n-}\n-\n test_atexit_cleanup=:\n test_atexit_handler () {\n \t# In a succeeding test script 'test_atexit_handler' is invoked\n@@ -1193,7 +1116,7 @@ test_done () {\n \t# removed, so the commands can access pidfiles and socket files.\n \ttest_atexit_handler\n \n-\tfinalize_junit_xml\n+\tfinalize_test_output\n \n \tif test -z \"$HARNESS_ACTIVE\"\n \tthen\n@@ -1484,22 +1407,7 @@ fi\n # in subprocesses like git equals our $PWD (for pathname comparisons).\n cd -P \"$TRASH_DIRECTORY\" || exit 1\n \n-if test -n \"$write_junit_xml\"\n-then\n-\tjunit_xml_dir=\"$TEST_OUTPUT_DIRECTORY/out\"\n-\tmkdir -p \"$junit_xml_dir\"\n-\tjunit_xml_base=${0##*/}\n-\tjunit_xml_path=\"$junit_xml_dir/TEST-${junit_xml_base%.sh}.xml\"\n-\tjunit_attrs=\"name=\\\"${junit_xml_base%.sh}\\\"\"\n-\tjunit_attrs=\"$junit_attrs timestamp=\\\"$(TZ=UTC \\\n-\t\tdate +%Y-%m-%dT%H:%M:%S)\\\"\"\n-\twrite_junit_xml --truncate \"<testsuites>\" \"  <testsuite $junit_attrs>\"\n-\tjunit_suite_start=$(test-tool date getnanos)\n-\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n-\tthen\n-\t\tGIT_TEST_TEE_OFFSET=0\n-\tfi\n-fi\n+start_test_output \"$0\"\n \n # Convenience\n # A regexp to match 5 and 35 hexdigits\n-- \ngitgitgadget\n\n"},{"id":"449914","messageId":"c8b240af749225c1084c722aa150d212e38f2a89.1646130289.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"[PATCH v2 6/9] test(junit): avoid line feeds in XML attributes","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-03-01T10:24:46Z","receivedAt":"2022-03-01T10:25:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nIn the test case's output, we do want newline characters, but in the XML\nattributes we do not want them.\n\nHowever, the `xml_attr_encode` function always adds a Line Feed at the\nend (which are then encoded as `&#x0a;`, even for XML attributes.\n\nThis seems not to faze Azure Pipelines' XML parser, but it still is\nincorrect, so let's fix it.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib-junit.sh | 14 ++++++++++----\n 1 file changed, 10 insertions(+), 4 deletions(-)\n\ndiff --git a/t/test-lib-junit.sh b/t/test-lib-junit.sh\nindex 9d55d74d764..c959183c7e2 100644\n--- a/t/test-lib-junit.sh\n+++ b/t/test-lib-junit.sh\n@@ -50,7 +50,7 @@ finalize_test_case_output () {\n \t\t;;\n \tfailure)\n \t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n-\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \"$1\")\\\">\"\n+\t\tjunit_insert=\"$junit_insert $(xml_attr_encode --no-lf \"$1\")\\\">\"\n \t\tjunit_insert=\"$junit_insert $(xml_attr_encode \\\n \t\t\t\"$(if test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n \t\t\t   then\n@@ -74,12 +74,12 @@ finalize_test_case_output () {\n \t\tset \"$* (known breakage)\"\n \t\t;;\n \tskip)\n-\t\tmessage=\"$(xml_attr_encode \"$skipped_reason\")\"\n+\t\tmessage=\"$(xml_attr_encode --no-lf \"$skipped_reason\")\"\n \t\tset \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n \t\t;;\n \tesac\n \n-\tjunit_attrs=\"name=\\\"$(xml_attr_encode \"$this_test.$test_count $1\")\\\"\"\n+\tjunit_attrs=\"name=\\\"$(xml_attr_encode --no-lf \"$this_test.$test_count $1\")\\\"\"\n \tshift\n \tjunit_attrs=\"$junit_attrs classname=\\\"$this_test\\\"\"\n \tjunit_attrs=\"$junit_attrs time=\\\"$(test-tool \\\n@@ -122,5 +122,11 @@ write_junit_xml () {\n }\n \n xml_attr_encode () {\n-\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n+\tif test \"x$1\" = \"x--no-lf\"\n+\tthen\n+\t\tshift\n+\t\tprintf '%s' \"$*\" | test-tool xml-encode\n+\telse\n+\t\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n+\tfi\n }\n-- \ngitgitgadget\n\n"},{"id":"449915","messageId":"15f199e810e08701b0c3bb84f1e9737672c100d9.1646130289.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"[PATCH v2 7/9] ci: optionally mark up output in the GitHub workflow","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-03-01T10:24:47Z","receivedAt":"2022-03-01T10:25:12Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nA couple of commands exist to spruce up the output in GitHub workflows:\nhttps://docs.github.com/en/actions/learn-github-actions/workflow-commands-for-github-actions\n\nIn addition to the `::group::<label>`/`::endgroup::` commands (which we\nalready use to structure the output of the build step better), we also\nuse `::error::`/`::notice::` to draw the attention to test failures and\nto test cases that were expected to fail but didn't.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib-functions.sh              |  4 +--\n t/test-lib-github-workflow-markup.sh | 50 ++++++++++++++++++++++++++++\n t/test-lib.sh                        |  5 ++-\n 3 files changed, 56 insertions(+), 3 deletions(-)\n create mode 100644 t/test-lib-github-workflow-markup.sh\n\ndiff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\nindex c3d38aaccbd..b5fe5f66085 100644\n--- a/t/test-lib-functions.sh\n+++ b/t/test-lib-functions.sh\n@@ -719,7 +719,7 @@ test_verify_prereq () {\n }\n \n test_expect_failure () {\n-\ttest_start_\n+\ttest_start_ \"$@\"\n \ttest \"$#\" = 3 && { test_prereq=$1; shift; } || test_prereq=\n \ttest \"$#\" = 2 ||\n \tBUG \"not 2 or 3 parameters to test-expect-failure\"\n@@ -739,7 +739,7 @@ test_expect_failure () {\n }\n \n test_expect_success () {\n-\ttest_start_\n+\ttest_start_ \"$@\"\n \ttest \"$#\" = 3 && { test_prereq=$1; shift; } || test_prereq=\n \ttest \"$#\" = 2 ||\n \tBUG \"not 2 or 3 parameters to test-expect-success\"\ndiff --git a/t/test-lib-github-workflow-markup.sh b/t/test-lib-github-workflow-markup.sh\nnew file mode 100644\nindex 00000000000..d8dc969df4a\n--- /dev/null\n+++ b/t/test-lib-github-workflow-markup.sh\n@@ -0,0 +1,50 @@\n+# Library of functions to mark up test scripts' output suitable for\n+# pretty-printing it in GitHub workflows.\n+#\n+# Copyright (c) 2022 Johannes Schindelin\n+#\n+# This program is free software: you can redistribute it and/or modify\n+# it under the terms of the GNU General Public License as published by\n+# the Free Software Foundation, either version 2 of the License, or\n+# (at your option) any later version.\n+#\n+# This program is distributed in the hope that it will be useful,\n+# but WITHOUT ANY WARRANTY; without even the implied warranty of\n+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n+# GNU General Public License for more details.\n+#\n+# You should have received a copy of the GNU General Public License\n+# along with this program.  If not, see http://www.gnu.org/licenses/ .\n+#\n+# The idea is for `test-lib.sh` to source this file when run in GitHub\n+# workflows; these functions will then override (empty) functions\n+# that are are called at the appropriate times during the test runs.\n+\n+start_test_output () {\n+\ttest -n \"$GIT_TEST_TEE_OUTPUT_FILE\" ||\n+\tdie \"--github-workflow-markup requires --verbose-log\"\n+\tgithub_markup_output=\"${GIT_TEST_TEE_OUTPUT_FILE%.out}.markup\"\n+\t>$github_markup_output\n+\tGIT_TEST_TEE_OFFSET=0\n+}\n+\n+# No need to override start_test_case_output\n+\n+finalize_test_case_output () {\n+\ttest_case_result=$1\n+\tshift\n+\tcase \"$test_case_result\" in\n+\tfailure)\n+\t\techo >>$github_markup_output \"::error::failed: $this_test.$test_count $1\"\n+\t\t;;\n+\tfixed)\n+\t\techo >>$github_markup_output \"::notice::fixed: $this_test.$test_count $1\"\n+\t\t;;\n+\tesac\n+\techo >>$github_markup_output \"::group::$test_case_result: $this_test.$test_count $*\"\n+\ttest-tool >>$github_markup_output path-utils skip-n-bytes \\\n+\t\t\"$GIT_TEST_TEE_OUTPUT_FILE\" $GIT_TEST_TEE_OFFSET\n+\techo >>$github_markup_output \"::endgroup::\"\n+}\n+\n+# No need to override finalize_test_output\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex e13e1cb9124..076bee58c19 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -174,6 +174,9 @@ parse_option () {\n \t--write-junit-xml)\n \t\t. \"$TEST_DIRECTORY/test-lib-junit.sh\"\n \t\t;;\n+\t--github-workflow-markup)\n+\t\t. \"$TEST_DIRECTORY/test-lib-github-workflow-markup.sh\"\n+\t\t;;\n \t--stress)\n \t\tstress=t ;;\n \t--stress=*)\n@@ -1027,7 +1030,7 @@ test_start_ () {\n \ttest_count=$(($test_count+1))\n \tmaybe_setup_verbose\n \tmaybe_setup_valgrind\n-\tstart_test_case_output\n+\tstart_test_case_output \"$@\"\n }\n \n test_finish_ () {\n-- \ngitgitgadget\n\n"},{"id":"449916","messageId":"91ea54f36c5724f08cd784b50519d628fd73f1a4.1646130289.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"[PATCH v2 8/9] ci: use `--github-workflow-markup` in the GitHub workflow","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-03-01T10:24:48Z","receivedAt":"2022-03-01T10:25:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nThis makes the output easier to digest.\n\nNote: since workflow output currently cannot contain any nested groups\n(see https://github.com/actions/runner/issues/802 for details), we need\nto remove the explicit grouping that would span the entirety of each\nfailed test script.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/lib.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 2a1b22db12a..7cc000e075c 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -177,7 +177,7 @@ then\n \t\t\ttest_name=\"${test_exit%.exit}\"\n \t\t\ttest_name=\"${test_name##*/}\"\n \t\t\tprintf \"\\\\e[33m\\\\e[1m=== Failed test: ${test_name} ===\\\\e[m\\\\n\"\n-\t\t\tgroup \"Failed test: $test_name\" cat \"t/test-results/$test_name.out\"\n+\t\t\tcat \"t/test-results/$test_name.markup\"\n \n \t\t\ttrash_dir=\"t/trash directory.$test_name\"\n \t\t\tcp \"t/test-results/$test_name.out\" t/failed-test-artifacts/\n@@ -189,7 +189,7 @@ then\n \tcache_dir=\"$HOME/none\"\n \n \texport GIT_PROVE_OPTS=\"--timer --jobs 10\"\n-\texport GIT_TEST_OPTS=\"--verbose-log -x\"\n+\texport GIT_TEST_OPTS=\"--verbose-log -x --github-workflow-markup\"\n \tMAKEFLAGS=\"$MAKEFLAGS --jobs=10\"\n \ttest windows != \"$CI_OS_NAME\" ||\n \tGIT_TEST_OPTS=\"--no-chain-lint --no-bin-wrappers $GIT_TEST_OPTS\"\n-- \ngitgitgadget\n\n"},{"id":"449917","messageId":"be2a83f5da3cdd74ee8d5166dea8170344185600.1646130289.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"[PATCH v2 9/9] ci: call `finalize_test_case_output` a little later","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-03-01T10:24:49Z","receivedAt":"2022-03-01T10:25:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nWe used to call that function already before printing the final verdict.\nHowever, now that we added grouping to the GitHub workflow output, we\nwill want to include even that part in the collapsible group for that\ntest case.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib.sh | 11 ++++++-----\n 1 file changed, 6 insertions(+), 5 deletions(-)\n\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 076bee58c19..1e683ad879b 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -732,30 +732,31 @@ trap '{ code=$?; set +x; } 2>/dev/null; exit $code' INT TERM HUP\n # the test_expect_* functions instead.\n \n test_ok_ () {\n-\tfinalize_test_case_output ok \"$@\"\n \ttest_success=$(($test_success + 1))\n \tsay_color \"\" \"ok $test_count - $@\"\n+\tfinalize_test_case_output ok \"$@\"\n }\n \n test_failure_ () {\n-\tfinalize_test_case_output failure \"$@\"\n+\tfailure_label=$1\n \ttest_failure=$(($test_failure + 1))\n \tsay_color error \"not ok $test_count - $1\"\n \tshift\n \tprintf '%s\\n' \"$*\" | sed -e 's/^/#\t/'\n \ttest \"$immediate\" = \"\" || _error_exit\n+\tfinalize_test_case_output failure \"$failure_label\" \"$@\"\n }\n \n test_known_broken_ok_ () {\n-\tfinalize_test_case_output fixed \"$@\"\n \ttest_fixed=$(($test_fixed+1))\n \tsay_color error \"ok $test_count - $@ # TODO known breakage vanished\"\n+\tfinalize_test_case_output fixed \"$@\"\n }\n \n test_known_broken_failure_ () {\n-\tfinalize_test_case_output broken \"$@\"\n \ttest_broken=$(($test_broken+1))\n \tsay_color warn \"not ok $test_count - $@ # TODO known breakage\"\n+\tfinalize_test_case_output broken \"$@\"\n }\n \n test_debug () {\n@@ -1081,10 +1082,10 @@ test_skip () {\n \n \tcase \"$to_skip\" in\n \tt)\n-\t\tfinalize_test_case_output skip \"$@\"\n \n \t\tsay_color skip \"ok $test_count # skip $1 ($skipped_reason)\"\n \t\t: true\n+\t\tfinalize_test_case_output skip \"$@\"\n \t\t;;\n \t*)\n \t\tfalse\n-- \ngitgitgadget\n"},{"id":"449936","messageId":"xmqqilsxsjib.fsf@gitster.g","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2203011111150.11118@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-01T16:52:12Z","receivedAt":"2022-03-01T16:52:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Let me again state my goal clearly, because some readers seem to be\n> confused and believe that I want to improve the developer experience of\n> veterans of the Git mailing list who are more than capable of finding\n> their way through the build failures.\n>\n> My goal is instead to make new contributors' lives easier.\n\nI understand who your primary target audiences are, and making them\nhappy without robbing too much from others is a good thing to do.\nInstead of \"Nah, this is not targetted for me\" and ignoring the\ntopic, I have been reporting my dogfood experience exactly to help\nthat process---to notice if this variant worsens end-user experience\nand see if that is within the reasonable pros-and-cons tolerance,\nespecially because they will start noticing the same hiccup as new\ncontributors stay longer and gain experiences.\n\n> In any case, thank you for integrating the patches into `seen` so that the\n> impact of the patches can be \"seen\".\n\nNo, do not thank me.  Thank yourself for writing it, and thank\nothers to try it and tell you their experiences to help you make it\nbetter.\n\nThanks.\n"},{"id":"449937","messageId":"xmqqee3lsj8q.fsf@gitster.g","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2203011109050.11118@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-01T16:57:57Z","receivedAt":"2022-03-01T16:58:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Yes, that's because line 5520 is the header of that group. If you direct\n> the reader to\n> https://github.com/git/git/runs/5343133021?check_suite_focus=true#step:4:5674\n> instead, it will get expanded.\n\nAh, that's a good trick to know.  I presume 5674 can be any random\nline in the block that is hidden by default that I want the viewer\nto expand, right?\n\n> If it would not get expanded, that would be a bug, but obviously not in my\n> patch series.\n\nWell, the choice to use a mechanism that has such a bug is made by\nthis patch series.  If \"allowing users to easily exchange a URL that\npoints the exact place that the tests broke\" were one of the goals,\nit does not matter whose fault it is---the aggregate result is that\nthe new UI would have failed that goal.\n\nThankfully there does not seem to be such a bug in the UI mechanism\nused by this series, so we are in good shape.\n\nThanks.\n"},{"id":"449987","messageId":"xmqqy21tpk4j.fsf@gitster.g","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-01T19:07:08Z","receivedAt":"2022-03-01T19:07:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Johannes Schindelin via GitGitGadget\" <gitgitgadget@gmail.com>\nwrites:\n\n> Changes since v1:\n>\n>  * In the patch that removed MAKE_TARGETS, a stale comment about that\n>    variable is also removed.\n>  * The comment about set -x has been adjusted because it no longer applies\n>    as-is.\n>  * The commit message of \"ci: make it easier to find failed tests' logs in\n>    the GitHub workflow\" has been adjusted to motivate the improvement\n>    better.\n\nWill queue.  Thanks.\n"},{"id":"450075","messageId":"30dbc8fb-a1db-05bc-3dcb-070e11cf4715@gmail.com","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2202251440330.11118@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2022-03-02T10:58:48Z","receivedAt":"2022-03-02T10:58:54Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Dscho\n\nOn 25/02/2022 14:10, Johannes Schindelin wrote:\n> Hi Phillip,\n> \n> On Wed, 23 Feb 2022, Phillip Wood wrote:\n> \n>> On 22/02/2022 13:31, Ævar Arnfjörð Bjarmason wrote:\n>>> [...]\n>>> So just to make the point about one of those mentioned in my [1] with\n>>> some further details (I won't go into the whole thing to avoid repeating\n>>> myself):\n>>>\n>>> I opened both of:\n>>>\n>>> https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true\n>>> https://github.com/dscho/git/runs/4840190622?check_suite_focus=true\n>>>\n>>> Just now in Firefox 91.5.0esr-1. Both having been opened before, so\n>>> they're in cache, and I've got a current 40MB/s real downlink speed etc.\n>>>\n>>> The former fully loads in around 5100ms, with your series here that's\n>>> just short of 18000ms.\n>>>\n>>> So your CI changes are making the common case of just looking at a CI\n>>> failure more than **3x as slow as before**.\n>>\n>> I don't think that is the most useful comparison between the two. When I\n>> am investigating a test failure the time that matters to me is the time\n>> it takes to display the output of the failing test case.\n> \n> Thank you for expressing this so clearly. I will adopt a variation of this\n> phrasing in my commit message, if you don't mind?\n\nThat's fine\n\n>> With the first link above the initial page load is faster but to get to\n>> the output of the failing test case I have click on \"Run\n>> ci/print_test_failures.sh\" then wait for that to load and then search\n>> for \"not ok\" to actually get to the information I'm after.\n> \n> And that's only because you are familiar with what you have to do.\n> \n> Any new contributor would be stuck with the information presented on the\n> initial load, without any indication that more information _is_ available,\n> just hidden away in the next step's log (which is marked as \"succeeding\",\n> therefore misleading the inclined reader into thinking that this cannot\n> potentially contain any information pertinent to the _failure_ that needs\n> to be investigated).\n\nYes it took we a while to realize how to get to the test output when I \nfirst started looking at the CI results.\n\nOne thing I forgot to mention was that when you expand a failing test it \nshows the test script twice before the output e.g.\n\nError: failed: t7527.35 Matrix[uc:false][fsm:true] enable fsmonitor\nfailure: t7527.35 Matrix[uc:false][fsm:true] enable fsmonitor\n   \t\t\t\tgit config core.fsmonitor true &&\n   \t\t\t\tgit fsmonitor--daemon start &&\n   \t\t\t\tgit update-index --fsmonitor\n   \t\t\t\n   expecting success of 7527.35 'Matrix[uc:false][fsm:true] enable \nfsmonitor':\n   \t\t\t\tgit config core.fsmonitor true &&\n   \t\t\t\tgit fsmonitor--daemon start &&\n   \t\t\t\tgit update-index --fsmonitor\n\n  ++ git config core.fsmonitor true\n  ++ git fsmonitor--daemon start \t\t\t\n  ...\n\nI don't know how easy it would be to fix that so that we only show \n\"expecting success of ...\" without the test being printed first\n\nBest Wishes\n\nPhillip\n\n\n>> With the second link the initial page load does feel slower but then I'm\n>> presented with the test failures nicely highlighted in red, all I have\n>> to do is click on one and I've got the information I'm after.\n>>\n>> Overall that is much faster and easier to use.\n> \n> Thank you for your comment. I really started to doubt myself, getting the\n> idea that it's just a case of me holding this thing wrong.\n> \n> For what it's worth, I did make a grave mistake by using that particular\n> `seen` CI failure with all of those failing p4 tests, which obviously\n> resulted in an incredibly large amount of logs. Obviously that _must_ be\n> slow to load. I just did not have the time to fabricate a CI failure.\n> \n> However, I do agree with you that the large amount of logs would have to\n> be looked at _anyway_, whether it is shown upon loading the job's logs or\n> only when expanding the `print-test-failures` step's logs. The amount of\n> the logs is a constant, after all, I did not change anything there (nor\n> would I).\n> \n> So a better example might be my concrete use case yesterday: the CI build\n> of `seen` failed. Here is the link to the regular output:\n> \n> \thttps://github.com/git/git/actions/runs/1890665968\n> \n> On that page, you see the following:\n> \n> \n> \tAnnotations\n> \t8 errors and 1 warning\n> \n> \tⓧ win test (3)\n> \t  Process completed with exit code 2.\n> \n> \tⓧ win test (6)\n> \t  Process completed with exit code 2.\n> \n> \tⓧ win test (2)\n> \t  Process completed with exit code 2.\n> \n> \tⓧ win+VS test (3)\n> \t  Process completed with exit code 2.\n> \n> \tⓧ win+VS test (6)\n> \t  Process completed with exit code 2.\n> \n> \tⓧ win+VS test (2)\n> \t  Process completed with exit code 2.\n> \n> \tⓧ osx-gcc (macos-latest)\n> \t  Process completed with exit code 2.\n> \n> \tⓧ osx-clang (macos-latest)\n> \t  Process completed with exit code 2.\n> \n> \t⚠ CI: .github#L1\n> \t  windows-latest workflows now use windows-2022. For more details, see https://github.com/actions/virtual-environments/issues/4856\n> \n> So I merged my branch into `seen` and pushed it. The corresponding run can\n> be seen here:\n> \n> \thttps://github.com/dscho/git/actions/runs/1892982393\n> \n> On that page, you see the following:\n> \n> \tAnnotations\n> \t50 errors and 1 warning\n> \n> \tⓧ win test (3)\n> \t  failed: t7527.1 explicit daemon start and stop\n> \n> \tⓧ win test (3)\n> \t  failed: t7527.2 implicit daemon start\n> \n> \tⓧ win test (3)\n> \t  failed: t7527.3 implicit daemon stop (delete .git)\n> \n> \tⓧ win test (3)\n> \t  failed: t7527.4 implicit daemon stop (rename .git)\n> \n> \tⓧ win test (3)\n> \t  failed: t7527.5 implicit daemon stop (rename GIT~1)\n> \n> \tⓧ win test (3)\n> \t  failed: t7527.6 implicit daemon stop (rename GIT~2)\n> \n> \tⓧ win test (3)\n> \t  failed: t7527.8 cannot start multiple daemons\n> \n> \tⓧ win test (3)\n> \t  failed: t7527.10 update-index implicitly starts daemon\n> \n> \tⓧ win test (3)\n> \t  failed: t7527.11 status implicitly starts daemon\n> \n> \tⓧ win test (3)\n> \t  failed: t7527.12 edit some files\n> \n> \tⓧ win test (2)\n> \t  failed: t0012.81 fsmonitor--daemon can handle -h\n> \n> \tⓧ win test (2)\n> \t  Process completed with exit code 1.\n> \n> \tⓧ win test (6)\n> \t  failed: t7519.2 run fsmonitor-daemon in bare repo\n> \n> \tⓧ win test (6)\n> \t  failed: t7519.3 run fsmonitor-daemon in virtual repo\n> \n> \tⓧ win test (6)\n> \t  Process completed with exit code 1.\n> \n> \tⓧ win+VS test (3)\n> \t  failed: t7527.1 explicit daemon start and stop\n> \n> \tⓧ win+VS test (3)\n> \t  failed: t7527.2 implicit daemon start\n> \n> \tⓧ win+VS test (3)\n> \t  failed: t7527.3 implicit daemon stop (delete .git)\n> \n> \tⓧ win+VS test (3)\n> \t  failed: t7527.4 implicit daemon stop (rename .git)\n> \n> \tⓧ win+VS test (3)\n> \t  failed: t7527.5 implicit daemon stop (rename GIT~1)\n> \n> \tⓧ win+VS test (3)\n> \t  failed: t7527.6 implicit daemon stop (rename GIT~2)\n> \n> \tⓧ win+VS test (3)\n> \t  failed: t7527.8 cannot start multiple daemons\n> \n> \tⓧ win+VS test (3)\n> \t  failed: t7527.10 update-index implicitly starts daemon\n> \n> \tⓧ win+VS test (3)\n> \t  failed: t7527.11 status implicitly starts daemon\n> \n> \tⓧ win+VS test (3)\n> \t  failed: t7527.12 edit some files\n> \n> \tⓧ win+VS test (2)\n> \t  failed: t0012.81 fsmonitor--daemon can handle -h\n> \n> \tⓧ win+VS test (2)\n> \t  Process completed with exit code 1.\n> \n> \tⓧ win+VS test (6)\n> \t  failed: t7519.2 run fsmonitor-daemon in bare repo\n> \n> \tⓧ win+VS test (6)\n> \t  failed: t7519.3 run fsmonitor-daemon in virtual repo\n> \n> \tⓧ win+VS test (6)\n> \t  Process completed with exit code 1.\n> \n> \tⓧ osx-clang (macos-latest)\n> \t  failed: t0012.81 fsmonitor--daemon can handle -h\n> \n> \tⓧ osx-clang (macos-latest)\n> \t  failed: t7519.2 run fsmonitor-daemon in bare repo\n> \n> \tⓧ osx-clang (macos-latest)\n> \t  failed: t7527.1 explicit daemon start and stop\n> \n> \tⓧ osx-clang (macos-latest)\n> \t  failed: t7527.2 implicit daemon start\n> \n> \tⓧ osx-clang (macos-latest)\n> \t  failed: t7527.3 implicit daemon stop (delete .git)\n> \n> \tⓧ osx-clang (macos-latest)\n> \t  failed: t7527.4 implicit daemon stop (rename .git)\n> \n> \tⓧ osx-clang (macos-latest)\n> \t  failed: t7527.7 MacOS event spelling (rename .GIT)\n> \n> \tⓧ osx-clang (macos-latest)\n> \t  failed: t7527.8 cannot start multiple daemons\n> \n> \tⓧ osx-clang (macos-latest)\n> \t  failed: t7527.10 update-index implicitly starts daemon\n> \n> \tⓧ osx-clang (macos-latest)\n> \t  failed: t7527.11 status implicitly starts daemon\n> \n> \tⓧ osx-gcc (macos-latest)\n> \t  failed: t0012.81 fsmonitor--daemon can handle -h\n> \n> \tⓧ osx-gcc (macos-latest)\n> \t  failed: t7519.2 run fsmonitor-daemon in bare repo\n> \n> \tⓧ osx-gcc (macos-latest)\n> \t  failed: t7527.1 explicit daemon start and stop\n> \n> \tⓧ osx-gcc (macos-latest)\n> \t  failed: t7527.2 implicit daemon start\n> \n> \tⓧ osx-gcc (macos-latest)\n> \t  failed: t7527.3 implicit daemon stop (delete .git)\n> \n> \tⓧ osx-gcc (macos-latest)\n> \t  failed: t7527.4 implicit daemon stop (rename .git)\n> \n> \tⓧ osx-gcc (macos-latest)\n> \t  failed: t7527.7 MacOS event spelling (rename .GIT)\n> \n> \tⓧ osx-gcc (macos-latest)\n> \t  failed: t7527.8 cannot start multiple daemons\n> \n> \tⓧ osx-gcc (macos-latest)\n> \t  failed: t7527.10 update-index implicitly starts daemon\n> \n> \tⓧ osx-gcc (macos-latest)\n> \t  failed: t7527.11 status implicitly starts daemon\n> \n> \t⚠ CI: .github#L1\n> \t  windows-latest workflows now use windows-2022. For more details, see https://github.com/actions/virtual-environments/issues/4856\n> \n> In my mind, this is already an improvement. (Even if this is a _lot_ of\n> output, and a lot of individual errors, given that all of them are fixed\n> with a single, small patch to adjust an option usage string, but that's\n> not the fault of my patch series, but of the suggestion to put the check\n> for the option usage string linting into the `parse_options()` machinery\n> instead of into the static analysis job.)\n> \n> Since there are still plenty of failures, the page admittedly does load\n> relatively slowly. But that's not the time I was trying to optimize for.\n> My time comes at quite a premium these days, so if the computer has to\n> work a little harder while I can do something else, as long as it saves\n> _me_ time, I'll take that time. Every time.\n> \n> Ciao,\n> Dscho\n"},{"id":"450078","messageId":"220302.86mti87cj2.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-02T12:22:24Z","receivedAt":"2022-03-02T12:40:55Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Mar 01 2022, Johannes Schindelin via GitGitGadget wrote:\n\n> Changes since v1:\n>\n>  * In the patch that removed MAKE_TARGETS, a stale comment about that\n>    variable is also removed.\n>  * The comment about set -x has been adjusted because it no longer applies\n>    as-is.\n>  * The commit message of \"ci: make it easier to find failed tests' logs in\n>    the GitHub workflow\" has been adjusted to motivate the improvement\n>    better.\n\nJust briefly: Much of the feedback I had on v1 is still unanswered, or\nin the case of the performance issues I think just saying that this\noutput is aimed at non-long-time-contributors doesn't really justify the\nlarge observed slowdowns.\n\nI've been clicking around on the various \"seen\" links you posted, and\nwhile some of the output is improved it's *much* slower, to the point\nwhere I don't find those gains worth it.\n\nFor the early part of this series teaching the \"ci/\" this GitHub\nmarkdown that's something that's unnecessary in my alternate approach in\n[1]. This series is is obviously a relatively shorter way to get there,\nbut knowing that you *can* do it in a simpler way now it's odd that the\nv2 doesn't discuss why getting from \"A\" to that \"B\" is still desirable\nwith this method.\n\nAs for the later parts:\n\n>   5:  94dcbe1bc43 =  5:  9eda6574313 tests: refactor --write-junit-xml code\n>   6:  41230100091 =  6:  c8b240af749 test(junit): avoid line feeds in XML attributes\n>   7:  98b32630fcd =  7:  15f199e810e ci: optionally mark up output in the GitHub workflow\n>   8:  1a6bd1846bc =  8:  91ea54f36c5 ci: use `--github-workflow-markup` in the GitHub workflow\n>   9:  992b1575889 =  9:  be2a83f5da3 ci: call `finalize_test_case_output` a little later\n\nI think (and I pointed out to you before) that I really don't see why\nteaching the test-lib.sh N output formats when we already have a\nmachine-readable output format with TAP *and* are in fact running code\nwith \"prove\" that is parsing that output format into nicely arranged\nobjects/structures makes sense.\n\nSo as a demo for how that can work, here's a quick POC I hacked up a\nwhile ago to use \"prove\" output plugins for this sort of thing.\n\nFirst we intentionally break a test:\n\n\t$ git -P diff\n\tdiff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh\n\tindex 76052cb5620..f085188baf9 100755\n\t--- a/t/t0002-gitfile.sh\n\t+++ b/t/t0002-gitfile.sh\n\t@@ -44,7 +44,7 @@ test_expect_success 'check hash-object' '\n\t \n\t test_expect_success 'check cat-file' '\n\t        git cat-file blob $SHA >actual &&\n\t-       test_cmp bar actual\n\t+       test_cmp /dev/null actual\n\t '\n\t \n\t test_expect_success 'check update-index' '\n\t@@ -67,7 +67,7 @@ test_expect_success 'check commit-tree' '\n\t \n\t test_expect_success 'check rev-list' '\n\t        git update-ref \"HEAD\" \"$SHA\" &&\n\t-       test \"$SHA\" = \"$(git rev-list HEAD)\"\n\t+       test \"$SHA\" = \"$(xgit rev-list HEAD)\"\n\t '\n\nAnd here's the resulting output, which is the same as the existing\n\"prove\" summary output, but then followed by nicely formatted details\nabout just the failing tests:\n\n\t$ PERL5LIB=$PWD prove --formatter Fmt t0002-gitfile.sh :: -vx\n\t \n\t test_expect_success 'setup_git_dir twice in subdir' '\n\tt0002-gitfile.sh .. Dubious, test returned 1 (wstat 256, 0x100)\n\tFailed 2/14 subtests \n\t\n\tTest Summary Report\n\t-------------------\n\tt0002-gitfile.sh (Wstat: 256 Tests: 14 Failed: 2)\n\t  Failed tests:  6, 10\n\t  Non-zero exit status: 1\n\tFiles=1, Tests=14,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.13 cusr  0.05 csys =  0.20 CPU)\n\tResult: FAIL\n\tFailed in t0002-gitfile.sh#6:\n\t ==> test   => not ok 6 - check cat-file\n\t ==> source => #\n\t ==> source => #        git cat-file blob $SHA >actual &&\n\t ==> source => #        test_cmp /dev/null actual\n\t ==> source => #\n\t ==> trace  => + git cat-file blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\t ==> trace  => + test_cmp /dev/null actual\n\t ==> trace  => + test 2 -ne 2\n\t ==> trace  => + eval diff -u \"$@\"\n\t ==> trace  => + diff -u /dev/null actual\n\t ==> output => --- /dev/null    2022-01-25 04:40:50.187529644 +0000\n\t ==> output => +++ actual       2022-03-02 12:29:28.217960535 +0000\n\t ==> output => @@ -0,0 +1 @@\n\t ==> output => +foo\n\t ==> output => error: last command exited with $?=1\n\t ==> output => \n\tFailed in t0002-gitfile.sh#10:\n\t ==> test   => not ok 10 - check rev-list\n\t ==> source => #\n\t ==> source => #        git update-ref \"HEAD\" \"$SHA\" &&\n\t ==> source => #        test \"$SHA\" = \"$(xgit rev-list HEAD)\"\n\t ==> source => #\n\t ==> trace  => + git update-ref HEAD f2e10ff57e8c01fe514c650d9de97e913257ba0c\n\t ==> trace  => + xgit rev-list HEAD\n\t ==> trace  => + test f2e10ff57e8c01fe514c650d9de97e913257ba0c = \n\t ==> output => t0002-gitfile.sh: 5: eval: xgit: not found\n\t ==> output => error: last command exited with $?=1\n\t ==> output => \n\nNow, some of that is on top of some output changes to test-lib.sh I had\nlocally, but the \"test\", \"source\" etc. there is not a hardcoded part of\nthe output, it's corresponding to (some of which I re-labeled,\ne.g. \"comment\" => \"source\") the individual object types the TAP::Parser\nemits.\n\nThe code to do that is below, with brief (unindented) comments:\n\n\tpackage Git::TAP::Formatter::Session;\n\tuse v5.18.2;\n\tuse strict;\n\tuse warnings;\n\tuse base 'TAP::Formatter::Console::ParallelSession';\n\t\n\tour %STATE;\n\tsub result {\n\t\tmy $self = shift;\n\t\tmy $result = shift;\n\nSo here we just have the TAP object for the current tests (as in \"ok\",\n\"not ok\" etc.), and save all of those away (both for successful and\nnon-successful) tests in %STATE for later:\n\t\n\t\tmy $res = $self->SUPER::result($result);\n\t\tmy $test_name = $self->name;\n\t\n\t\t# An AoO of test numbers and their output lines\n\t\t$STATE{$test_name} ||= [{lines => []}];\n\t\n\t\tpush @{$STATE{$test_name}->[-1]->{lines}} => $result;\n\t\n\t\t# When we see a new test add a new AoA for its output. We do\n\t\t# end up with the \"plan\" type as part of the last test, and\n\t\t# might want to split it up\n\t\tif ($result->type eq 'test') {\n\t\t\tpush @{$STATE{$test_name}} => {};\n\t\t}\n\t\n\t\treturn $res;\n\t}\n\nThis \"Fmt\" package is a \"prove\" plugin. It's just hooking into the code\nthat emits the current summary, now it just shows the \"Test Summary\nReport\" that your CL notes issues with, but this shows how easy it is to\nchange or amend it (you can override another accessor here to fully\nsuppress the current output, I just didn't do that):\n\n\tpackage Fmt;\n\tuse strict;\n\tuse warnings;\n\tuse List::MoreUtils qw(firstidx);\n\tuse base 'TAP::Formatter::Console';\n\t\n\tsub open_test {\n\t\tmy $self = shift;\n\t\n\t\tmy $session = $self->SUPER::open_test(@_);\n\t\tuse Data::Dumper;\n\t\t#warn \"session is = \" . Dumper $session;\n\t\treturn bless $session => 'Git::TAP::Formatter::Session';\n\t}\n\t\n\tsub summary {\n\t\tmy $self = shift;\n\t\t$self->SUPER::summary(@_);\n\t\n\t\t## This state machine needs to go past the \"ok\" line and grab\n\t\t## the comments emitted by e.g. \"say_color_tap_comment_lines\" in\n\t\t## test_ok_()\n\t\tfor my $test (sort keys %STATE) {\n\t\t\tfor (my $i = 1; $i <= $#{$STATE{$test}}; $i++) {\n\t\t\t\tmy @lines = @{$STATE{$test}->[$i]->{lines}};\n\t\t\t\tmy $break = firstidx { $_->raw eq '' } @lines;\n\t\t\t\tmy @source = splice @lines, 0, $break;\n\t\n\t\t\t\tsplice @lines, 0, 1; # Splice out the '' item\n\t\t\t\tpush @{$STATE{$test}->[$i - 1]->{lines}} => @source;\n\t\n\t\t\t\t$STATE{$test}->[$i]->{lines} = \\@lines;\n\t\n\t\t\t\t# Since we parsed out the source already,\n\t\t\t\t# let's make it easily machine-readable, and\n\t\t\t\t# parse the rest.\n\t\t\t\t$STATE{$test}->[$i]->{source} = \\@source;\n\t\t\t\tmy @trace = map { $_->{is_trace} = 1 } grep { $_->raw =~ /^\\+ / } @lines;\n\t\t\t\t$STATE{$test}->[$i]->{trace} = \\@trace if @trace;\n\t\t\t}\n\t\t}\n\t\n\t\tmy $aggregator = $_[0];\n\t\tfor my $failed ($aggregator->failed) {\n\t\t\tmy ($parser) = $aggregator->parsers($failed);\n\t\t\tfor my $i ($parser->failed) {\n\t\t\t\tmy $idx = $i - 1;\n\t\t\t\tmy @lines = @{$STATE{$failed}->[$idx]->{lines}};\n\t\t\t\tmy ($test) = grep { $_->is_test } @lines;\n\t\n\t\t\t\tsay \"Failed in $failed#$i:\";\n\t\t\t\tsay join \"\\n\", map {\n\t\t\t\t\ts/^/ ==> /gr;\n\t\t\t\t} map {\n\t\t\t\t\tsprintf(\"%-6s => %s\",\n\t\t\t\t\t     $_->{is_trace} ? \"trace\" :\n\t\t\t\t\t     $_->is_unknown ? \"output\" :\n\t\t\t\t\t     $_->is_comment ? \"source\" :\n\t\t\t\t\t     $_->type,\n\t\t\t\t\t     $_->raw,\n\t\t\t\t     );\n\t\t\t\t} sort {\n\t\t\t\t\t# the \"is_trace\" may be undef\n\t\t\t\t\tno warnings qw(uninitialized);\n\t\t\t\t\t# The \"[not ]ok\" line first...\n\t\t\t\t\t$b->is_test <=> $a->is_test ||\n\t\t\t\t\t# Then \"comment\" (i.e. test source)\n\t\t\t\t\t$b->is_comment <=> $a->is_comment ||\n\t\t\t\t\t# Then the \"+ \" trace of execution\n\t\t\t\t\t$b->{is_trace} <=> $a->{is_trace}\n\t\t\t\t} @lines;\n\t\t\t}\n\t\t}\n\t}\n\t\n\t1;\n\n\n1. https://lore.kernel.org/git/cover-00.25-00000000000-20220221T143936Z-avarab@gmail.com/\n2. https://lore.kernel.org/git/220222.86y2236ndp.gmgdl@evledraar.gmail.com/\n"},{"id":"450361","messageId":"xmqqee3i2mlw.fsf_-_@gitster.g","threadId":"57297","inReplyTo":"xmqqv8x2dd7j.fsf@gitster.g","subject":"win+VS environment has \"cut\" but not \"paste\"?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-04T07:38:51Z","receivedAt":"2022-03-04T07:38:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"GitHub CI seems to fail due to lack of \"paste\" for win+VS job.  This\nwas somewhat unexpected, as our test scripts seem to make liberal\nuse of \"cut\" that goes together with it.\n\n    https://github.com/git/git/runs/5415486631?check_suite_focus=true#step:5:6199\n\nThe particular failure at the URL comes from the use of \"paste\" in\n5ea4f3a5 (name-rev: use generation numbers if available,\n2022-02-28), but it hardly is the first use of the command.  There\nis one use of it in t/aggregate-results.sh in 'master/main' already.\n\nWe could rewrite the tests that use \"paste\" but looking at the use\nof the tool in the test (and the aggregate thing), rewriting them\ndue to lack of a tool, whose source should be freely available from\nwhere \"cut\" was taken from, does not sound like too attractive a\ndirection to go in, but I do not know how much work is involved in\nadding it (and in general, any basic tool with similar complexity\nthat we may find missing in the future) to the win+VS environment.\n\nThoughts?\n\nThanks.\n\n\n"},{"id":"450365","messageId":"220304.86mti6f4ny.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"xmqqee3i2mlw.fsf_-_@gitster.g","subject":"Re: win+VS environment has \"cut\" but not \"paste\"?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-04T09:04:23Z","receivedAt":"2022-03-04T09:28:08Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Mar 03 2022, Junio C Hamano wrote:\n\n> GitHub CI seems to fail due to lack of \"paste\" for win+VS job.  This\n> was somewhat unexpected, as our test scripts seem to make liberal\n> use of \"cut\" that goes together with it.\n>\n>     https://github.com/git/git/runs/5415486631?check_suite_focus=true#step:5:6199\n>\n> The particular failure at the URL comes from the use of \"paste\" in\n> 5ea4f3a5 (name-rev: use generation numbers if available,\n> 2022-02-28), but it hardly is the first use of the command.  There\n> is one use of it in t/aggregate-results.sh in 'master/main' already.\n\nI think it's the first use, the t/aggregate-results.sh is run on\n\"DEFAULT_TEST_TARGET=test make -C t\", but we use\n\"DEFAULT_TEST_TARGET=prove\".\n\nRe your upthread:\n\n> I personally do not care about the initial latency when viewing the\n> output from CI run that may have happened a few dozens of minutes\n> ago (I do not sit in front of GitHub CI UI and wait until it\n> finishes). \n\nI think this URL is a good example of what I noted in [1]. Your link\nloads relatively quickly, but I then saw a \"linux-TEST-vars\" failure and\nclicked on it, wanting to see why that fails.\n\nIt opens relatively quickly, but no failure can be seen. It stalls with\na spinner next to \"t/run-build-and-test.sh\", and stalled like that for\n75[2] seconds before finally loading past line ~3.5k to line ~70k\nshowing the relevant failure in t6120*.sh.\n\nI really don't think it's a reasonable claim to say that only \"veterans\"\nof git development[3] are likely to find the workflow of seeing a CI\nfailure right away useful, or wanting to browse through the N different\n\"job\" failures without having to pre-open them, go find something else\nto do, then come back to it etc.\n\nI also noted in [1] that it takes a lot more CPU now, so even if that is\nyour workflow for looking at CI you'll need a fairly performant machine\nif you have a few job failures (which isn't a typical), as each tab will\nbe pegging a CPU core at ~100% for a while.\n\nI have fairly normally spec'd quad-core laptop that I almost never hear,\nand this new CI UI is pretty reliable in making it sound as though it's\nabout to take flight.\n\n1. https://lore.kernel.org/git/220222.86tucr6kz5.gmgdl@evledraar.gmail.com/\n2. I reported large N seconds, but nothing so bad before. For some reason\n   this one's particularly bad, but in [1] it was the same CPU use with ~20s\n   etc (but that one was 1/2 the amount of lines)\n3. https://lore.kernel.org/git/nycvar.QRO.7.76.6.2203011111150.11118@tvgsbejvaqbjf.bet/\n"},{"id":"450593","messageId":"nycvar.QRO.7.76.6.2203071646500.11118@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"xmqqee3i2mlw.fsf_-_@gitster.g","subject":"Re: win+VS environment has \"cut\" but not \"paste\"?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-03-07T15:48:44Z","receivedAt":"2022-03-07T15:49:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 3 Mar 2022, Junio C Hamano wrote:\n\n> GitHub CI seems to fail due to lack of \"paste\" for win+VS job.  This\n> was somewhat unexpected, as our test scripts seem to make liberal\n> use of \"cut\" that goes together with it.\n>\n>     https://github.com/git/git/runs/5415486631?check_suite_focus=true#step:5:6199\n>\n> The particular failure at the URL comes from the use of \"paste\" in\n> 5ea4f3a5 (name-rev: use generation numbers if available,\n> 2022-02-28), but it hardly is the first use of the command.  There\n> is one use of it in t/aggregate-results.sh in 'master/main' already.\n>\n> We could rewrite the tests that use \"paste\" but looking at the use\n> of the tool in the test (and the aggregate thing), rewriting them\n> due to lack of a tool, whose source should be freely available from\n> where \"cut\" was taken from, does not sound like too attractive a\n> direction to go in, but I do not know how much work is involved in\n> adding it (and in general, any basic tool with similar complexity\n> that we may find missing in the future) to the win+VS environment.\n\nI added it:\nhttps://github.com/git-for-windows/git-sdk-64/commit/e3ade7eef2503149dfefe630037c2fd6d24f2c14\n\nIt will take ~35 minutes (at time of writing) for\nhttps://dev.azure.com/Git-for-Windows/git/_build/results?buildId=95542&view=results\nto make the corresponding artifact available to the\n`setup-git-for-windows-sdk` Action we use.\n\nCiao,\nDscho\n"},{"id":"450594","messageId":"nycvar.QRO.7.76.6.2203071649100.11118@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"220304.86mti6f4ny.gmgdl@evledraar.gmail.com","subject":"Re: win+VS environment has \"cut\" but not \"paste\"?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-03-07T15:51:07Z","receivedAt":"2022-03-07T15:51:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ævar,\n\nOn Fri, 4 Mar 2022, Ævar Arnfjörð Bjarmason wrote:\n\n> I really don't think it's a reasonable claim to say that only \"veterans\"\n> of git development[3] are likely to find the workflow of seeing a CI\n> failure right away useful, or wanting to browse through the N different\n> \"job\" failures without having to pre-open them, go find something else\n> to do, then come back to it etc.\n\nI said that the current output is only useful to veterans. The output that\nhides the detailed log, under a separate job that is marked as\nnon-failing.\n\nThat's still as true as when I said it. :-)\n\nCiao,\nJohannes\n"},{"id":"450597","messageId":"nycvar.QRO.7.76.6.2203071655070.11118@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"220302.86mti87cj2.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-03-07T15:57:04Z","receivedAt":"2022-03-07T15:57:15Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ævar,\n\nOn Wed, 2 Mar 2022, Ævar Arnfjörð Bjarmason wrote:\n\n>\n> On Tue, Mar 01 2022, Johannes Schindelin via GitGitGadget wrote:\n>\n> > Changes since v1:\n> >\n> >  * In the patch that removed MAKE_TARGETS, a stale comment about that\n> >    variable is also removed.\n> >  * The comment about set -x has been adjusted because it no longer applies\n> >    as-is.\n> >  * The commit message of \"ci: make it easier to find failed tests' logs in\n> >    the GitHub workflow\" has been adjusted to motivate the improvement\n> >    better.\n>\n> Just briefly: Much of the feedback I had on v1 is still unanswered,\n\nYes, because I got the sense that your feedback ignores the goal of making\nit easier to diagnose test failures.\n\n> or in the case of the performance issues I think just saying that this\n> output is aimed at non-long-time-contributors doesn't really justify the\n> large observed slowdowns.\n\nWhat good is a quickly-loading web site when it is less than useful?\n\nI'd much rather have a slow-loading web site that gets me to where I need\nto be than a fast-loading one that leaves me as puzzled as before.\n\nCiao,\nJohannes\n"},{"id":"450599","messageId":"nycvar.QRO.7.76.6.2203071657180.11118@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"30dbc8fb-a1db-05bc-3dcb-070e11cf4715@gmail.com","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-03-07T16:07:41Z","receivedAt":"2022-03-07T16:07:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip,\n\nOn Wed, 2 Mar 2022, Phillip Wood wrote:\n\n> On 25/02/2022 14:10, Johannes Schindelin wrote:\n>\n> > On Wed, 23 Feb 2022, Phillip Wood wrote:\n> >\n> > > With the first link above the initial page load is faster but to get\n> > > to the output of the failing test case I have click on \"Run\n> > > ci/print_test_failures.sh\" then wait for that to load and then\n> > > search for \"not ok\" to actually get to the information I'm after.\n> >\n> > And that's only because you are familiar with what you have to do.\n> >\n> > Any new contributor would be stuck with the information presented on the\n> > initial load, without any indication that more information _is_ available,\n> > just hidden away in the next step's log (which is marked as \"succeeding\",\n> > therefore misleading the inclined reader into thinking that this cannot\n> > potentially contain any information pertinent to the _failure_ that needs\n> > to be investigated).\n>\n> Yes it took we a while to realize how to get to the test output when I first\n> started looking at the CI results.\n\nThank you for saying that. Since nobody else said it as clearly as you, I\nreally started to doubt myself here.\n\n> One thing I forgot to mention was that when you expand a failing test it shows\n> the test script twice before the output e.g.\n>\n> Error: failed: t7527.35 Matrix[uc:false][fsm:true] enable fsmonitor\n> failure: t7527.35 Matrix[uc:false][fsm:true] enable fsmonitor\n>   \t\t\t\tgit config core.fsmonitor true &&\n>   \t\t\t\tgit fsmonitor--daemon start &&\n>   \t\t\t\tgit update-index --fsmonitor\n>\n>   expecting success of 7527.35 'Matrix[uc:false][fsm:true] enable fsmonitor':\n>   \t\t\t\tgit config core.fsmonitor true &&\n>   \t\t\t\tgit fsmonitor--daemon start &&\n>   \t\t\t\tgit update-index --fsmonitor\n>\n>  ++ git config core.fsmonitor true\n>  ++ git fsmonitor--daemon start\n>  ...\n>\n> I don't know how easy it would be to fix that so that we only show \"expecting\n> success of ...\" without the test being printed first\n\nIt's not _super_ easy: right now, the patch series does not touch the code\nthat prints the latter message. In fact, that latter message is generated\n_before_ the test fails, and redirected via `tee` into\n`GIT_TEST_TEE_OUTPUT_FILE`. Then, once the verdict is clear that this test\ncase failed, the first message is printed (the one that is colored in the\noutput via `::error::`), and the output from the\n`GIT_TEST_TEE_OUTPUT_FILE` file is pasted, starting at the offset marking\nthe start of the test case.\n\nThe easiest workaround would probably to add a flag that suppresses the\nheader `expecting success` in case we're running with the\n`--github-workflow-markup` option.\n\nI'll put it on my ever-growing TODO list, but maybe in the interest of\nheeding the mantra \"the perfect is the enemy of the good\", this can be\ndone on top of this series rather than blocking it?\n\nThanks,\nDscho\n"},{"id":"450602","messageId":"220307.86tuc9yc4b.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2203071655070.11118@tvgsbejvaqbjf.bet","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-07T16:05:54Z","receivedAt":"2022-03-07T16:13:31Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Mar 07 2022, Johannes Schindelin wrote:\n\n> On Wed, 2 Mar 2022, Ævar Arnfjörð Bjarmason wrote:\n>\n>>\n>> On Tue, Mar 01 2022, Johannes Schindelin via GitGitGadget wrote:\n>>\n>> > Changes since v1:\n>> >\n>> >  * In the patch that removed MAKE_TARGETS, a stale comment about that\n>> >    variable is also removed.\n>> >  * The comment about set -x has been adjusted because it no longer applies\n>> >    as-is.\n>> >  * The commit message of \"ci: make it easier to find failed tests' logs in\n>> >    the GitHub workflow\" has been adjusted to motivate the improvement\n>> >    better.\n>>\n>> Just briefly: Much of the feedback I had on v1 is still unanswered,\n>\n> Yes, because I got the sense that your feedback ignores the goal of making\n> it easier to diagnose test failures.\n\nI think that's a rather strange conclusion given that I've submitted a\nparallel series that makes some of those failures easier to diagnose\nthan the same changes in this series. I.e. the failures in build\nv.s. test phases, not the individual test format output (but those are\northagonal).\n\nI think it's a fair summary of our differences that we're just placing\ndifferent values on UX responsiveness. I'm pretty sure there's some\namount of UX slowdown you'd consider unacceptable, no matter how much\nthe output was improved.\n\nClearly we just use it differently.\n\n>> or in the case of the performance issues I think just saying that this\n>> output is aimed at non-long-time-contributors doesn't really justify the\n>> large observed slowdowns.\n>\n> What good is a quickly-loading web site when it is less than useful?\n\nFor all the flaws in the current output there are cases now where you\ncan click on a failure, see a summary of the 1-2 tests that failed, and\neven find your way through the right place in the rather verbose raw log\noutput in 1/4 or 1/2 the time it takes the initial page on the new UX to\nloda.\n\n> I'd much rather have a slow-loading web site that gets me to where I need\n> to be than a fast-loading one that leaves me as puzzled as before.\n\nI think it's clear that we're going to disagree on this point, but I'd\nstill think that:\n\n * In a re-roll, you should amend these patches to clearly note that's a\n   UX trade-off you're making, perhaps with rough before/after timings\n   similar to the ones I've posted.\n\n   I.e. now those patches say nothing about the UX change resulting in\n   UX that's *much* slower than before. Clearly noting that trade-off\n   for reviewers is not the same as saying the trade-off can't be made.\n\n * I don't see why the changes here can't be made configurable (and\n   perhaps you'd argue they should be on by default) via the ci-config\n   phase.\n"},{"id":"450616","messageId":"xmqqr17du2cn.fsf@gitster.g","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2203071646500.11118@tvgsbejvaqbjf.bet","subject":"Re: win+VS environment has \"cut\" but not \"paste\"?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-07T16:58:00Z","receivedAt":"2022-03-07T16:58:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> GitHub CI seems to fail due to lack of \"paste\" for win+VS job.  This\n>> was somewhat unexpected, as our test scripts seem to make liberal\n>> use of \"cut\" that goes together with it.\n>> ...\n> I added it:\n> https://github.com/git-for-windows/git-sdk-64/commit/e3ade7eef2503149dfefe630037c2fd6d24f2c14\n\nThanks.\n"},{"id":"450617","messageId":"xmqqmti1u20m.fsf@gitster.g","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2203071649100.11118@tvgsbejvaqbjf.bet","subject":"Re: win+VS environment has \"cut\" but not \"paste\"?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-07T17:05:13Z","receivedAt":"2022-03-07T17:05:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> I said that the current output is only useful to veterans. The output that\n> hides the detailed log, under a separate job that is marked as\n> non-failing.\n>\n> That's still as true as when I said it. :-)\n\nI think getting rid of the separate \"print failures\" CI step and\nmaking it more discoverable how to reveal the details of failing\ntest step is a usability improvement.\n\nI am not Ævar, but I think what was questioned was the improvement\njustifies multi dozens of seconds extra waiting time, which is a\nusability dis-improvement.  I do not have a good answer to that\nquestion.\n\nI am probably nearing to be a veteran who knows when to brew my tea\nin my work cycle, and waiting for an extra minute or two while\nbrowsing CI output is not a problem for me.\n\nBut new \"non-veteran\" users may not share that.  That is something a\nbit worrying about the new UI.\n\nThanks.\n\n\n"},{"id":"450618","messageId":"xmqqilspu1pp.fsf@gitster.g","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2203071657180.11118@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-07T17:11:46Z","receivedAt":"2022-03-07T17:11:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> One thing I forgot to mention was that when you expand a failing test it shows\n>> the test script twice before the output e.g.\n>>\n>> Error: failed: t7527.35 Matrix[uc:false][fsm:true] enable fsmonitor\n>> failure: t7527.35 Matrix[uc:false][fsm:true] enable fsmonitor\n>>   \t\t\t\tgit config core.fsmonitor true &&\n>>   \t\t\t\tgit fsmonitor--daemon start &&\n>>   \t\t\t\tgit update-index --fsmonitor\n>>\n>>   expecting success of 7527.35 'Matrix[uc:false][fsm:true] enable fsmonitor':\n>>   \t\t\t\tgit config core.fsmonitor true &&\n>>   \t\t\t\tgit fsmonitor--daemon start &&\n>>   \t\t\t\tgit update-index --fsmonitor\n>>\n>>  ++ git config core.fsmonitor true\n>>  ++ git fsmonitor--daemon start\n>>  ...\n>>\n>> I don't know how easy it would be to fix that so that we only show \"expecting\n>> success of ...\" without the test being printed first\n>\n> It's not _super_ easy: right now, the patch series does not touch the code\n\nIn other words, it is not a new issue introduced by this series, right?\n\n> The easiest workaround would probably to add a flag that suppresses the\n> header `expecting success` in case we're running with the\n> `--github-workflow-markup` option.\n\nIf that is the case, let's leave it outside the series.\n\nIf we do not have to hide the solution behind any option specific to\n\"--github-workflow-markup\", then even users (like me) who reguarly\nrun \"cd t && sh ./t1234-a-particular-test.sh -i -v\" would benefit if\nwe no longer have to look at the duplicated test script in the\noutput.\n\nThanks.\n"},{"id":"450619","messageId":"dd45f032-9b42-c3f3-b3ae-78e3528d20aa@gmail.com","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2203071657180.11118@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2022-03-07T17:12:02Z","receivedAt":"2022-03-07T17:12:13Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Dscho\nOn 07/03/2022 16:07, Johannes Schindelin wrote:\n> Hi Phillip,\n> \n> On Wed, 2 Mar 2022, Phillip Wood wrote:\n> \n>> On 25/02/2022 14:10, Johannes Schindelin wrote:\n>>\n>>> On Wed, 23 Feb 2022, Phillip Wood wrote:\n>>>\n>>>> With the first link above the initial page load is faster but to get\n>>>> to the output of the failing test case I have click on \"Run\n>>>> ci/print_test_failures.sh\" then wait for that to load and then\n>>>> search for \"not ok\" to actually get to the information I'm after.\n>>>\n>>> And that's only because you are familiar with what you have to do.\n>>>\n>>> Any new contributor would be stuck with the information presented on the\n>>> initial load, without any indication that more information _is_ available,\n>>> just hidden away in the next step's log (which is marked as \"succeeding\",\n>>> therefore misleading the inclined reader into thinking that this cannot\n>>> potentially contain any information pertinent to the _failure_ that needs\n>>> to be investigated).\n>>\n>> Yes it took we a while to realize how to get to the test output when I first\n>> started looking at the CI results.\n> \n> Thank you for saying that. Since nobody else said it as clearly as you, I\n> really started to doubt myself here.\n> \n>> One thing I forgot to mention was that when you expand a failing test it shows\n>> the test script twice before the output e.g.\n>>\n>> Error: failed: t7527.35 Matrix[uc:false][fsm:true] enable fsmonitor\n>> failure: t7527.35 Matrix[uc:false][fsm:true] enable fsmonitor\n>>    \t\t\t\tgit config core.fsmonitor true &&\n>>    \t\t\t\tgit fsmonitor--daemon start &&\n>>    \t\t\t\tgit update-index --fsmonitor\n>>\n>>    expecting success of 7527.35 'Matrix[uc:false][fsm:true] enable fsmonitor':\n>>    \t\t\t\tgit config core.fsmonitor true &&\n>>    \t\t\t\tgit fsmonitor--daemon start &&\n>>    \t\t\t\tgit update-index --fsmonitor\n>>\n>>   ++ git config core.fsmonitor true\n>>   ++ git fsmonitor--daemon start\n>>   ...\n>>\n>> I don't know how easy it would be to fix that so that we only show \"expecting\n>> success of ...\" without the test being printed first\n> \n> It's not _super_ easy: right now, the patch series does not touch the code\n> that prints the latter message. In fact, that latter message is generated\n> _before_ the test fails, and redirected via `tee` into\n> `GIT_TEST_TEE_OUTPUT_FILE`. Then, once the verdict is clear that this test\n> case failed, the first message is printed (the one that is colored in the\n> output via `::error::`), and the output from the\n> `GIT_TEST_TEE_OUTPUT_FILE` file is pasted, starting at the offset marking\n> the start of the test case.\n> \n> The easiest workaround would probably to add a flag that suppresses the\n> header `expecting success` in case we're running with the\n> `--github-workflow-markup` option.\n> \n> I'll put it on my ever-growing TODO list, but maybe in the interest of\n> heeding the mantra \"the perfect is the enemy of the good\", this can be\n> done on top of this series rather than blocking it?\n\nSure, I mentioned it in case it was easy to fix but I don't think it \nshould stop these patches moving forward\n\nBest Wishes\n\nPhillip\n\n> Thanks,\n> Dscho\n\n"},{"id":"450624","messageId":"xmqqtuc9sm09.fsf@gitster.g","threadId":"57297","inReplyTo":"220307.86tuc9yc4b.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-07T17:36:22Z","receivedAt":"2022-03-07T17:36:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> I think that's a rather strange conclusion given that I've submitted a\n> parallel series that makes some of those failures easier to diagnose\n> than the same changes in this series. I.e. the failures in build\n> v.s. test phases, not the individual test format output (but those are\n> orthagonal).\n\nIf you have a counter-proposal that you feel is solid enough, I do\nnot mind dropping the topic in question and replacing it with the\ncounter-proposal to let people see how it fares for a few days.  If\nit allows others to view the output easily if you revert the merge\nof this topic into 'seen' and replace with the counter-proposal and\npush it to your own repository, that would be an even better way to\nhighlight the differences of two approaches, as that would allow us\nto see the same failures side-by-side.\n\nAm I correct to understand that one of the the common goals here is\nto eliminate the need to discover how to get to the first failure\noutput without turning it slow by 10x to load the output?\n\n> I think it's clear that we're going to disagree on this point, but I'd\n> still think that:\n>\n>  * In a re-roll, you should amend these patches to clearly note that's a\n>    UX trade-off you're making, perhaps with rough before/after timings\n>    similar to the ones I've posted.\n>\n>    I.e. now those patches say nothing about the UX change resulting in\n>    UX that's *much* slower than before. Clearly noting that trade-off\n>    for reviewers is not the same as saying the trade-off can't be made.\n\nWhether we perform counter-proposal comparison or not, the above is\na reasonable thing to ask.\n\n>  * I don't see why the changes here can't be made configurable (and\n>    perhaps you'd argue they should be on by default) via the ci-config\n>    phase.\n\nI do not know if such a knob is feasible, though.\n\nThanks.\n"},{"id":"450829","messageId":"220309.861qzbnymn.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"xmqqtuc9sm09.fsf@gitster.g","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-09T10:56:41Z","receivedAt":"2022-03-09T11:39:37Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Mar 07 2022, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> I think that's a rather strange conclusion given that I've submitted a\n>> parallel series that makes some of those failures easier to diagnose\n>> than the same changes in this series. I.e. the failures in build\n>> v.s. test phases, not the individual test format output (but those are\n>> orthagonal).\n>\n> If you have a counter-proposal that you feel is solid enough, I do\n> not mind dropping the topic in question and replacing it with the\n> counter-proposal to let people see how it fares for a few days.  If\n> it allows others to view the output easily if you revert the merge\n> of this topic into 'seen' and replace with the counter-proposal and\n> push it to your own repository, that would be an even better way to\n> highlight the differences of two approaches, as that would allow us\n> to see the same failures side-by-side.\n\nI proposed [1] as a counter-proposal to *part of* this series, which has\nvarious UX comparisons.\n\nNote that it doesn't aim to change the test failure output\nsignificantly, but to structurally simplify .github/workflows/main.yml\nand ci/ for a significant line-count reduction, and improve part of the\noutput that we get for \"make\" v.s. \"make test\", and to make it obvious\nwhat the parameters of each step are.\n\nWhich is partially overlapping with 1/2 of Johannes's series here, I\nthink it makes sense to split up those two concerns & address this more\nincrementally.\n\nI.e. my series shows that you can get what the first half of this series\nproposes to do by adding GitHub-specific output to ci/* without any such\nCI-backend-specific output, and the resulting presentation in the UX is\nbetter.\n\nIt'll still apply to \"master\" with this topic ejected, there was a minor\ncomment (needing commit message rephrasing) from SZEDER Gábor on it, I\ncould re-roll it if you're interested.\n\n> Am I correct to understand that one of the the common goals here is\n> to eliminate the need to discover how to get to the first failure\n> output without turning it slow by 10x to load the output?\n\nThat's definitely an eventual common goal, I have a POC for how to do\nthat with an alternate approach that doesn't suffer from that slowdown,\nand shows you much more targeted failure output (only the specific tests\nthat failed) at [2].\n\nI just think it makes sense to split up the concerns how we arrange\n.github/workflows/main.yml & ci/* and how doing that differently can\nimprove the CI UX, v.s. the mostly orthagonal concern of how test-lib.sh\n+ prove can best summarize their failure output.\n\n>> I think it's clear that we're going to disagree on this point, but I'd\n>> still think that:\n>>\n>>  * In a re-roll, you should amend these patches to clearly note that's a\n>>    UX trade-off you're making, perhaps with rough before/after timings\n>>    similar to the ones I've posted.\n>>\n>>    I.e. now those patches say nothing about the UX change resulting in\n>>    UX that's *much* slower than before. Clearly noting that trade-off\n>>    for reviewers is not the same as saying the trade-off can't be made.\n>\n> Whether we perform counter-proposal comparison or not, the above is\n> a reasonable thing to ask.\n>\n>>  * I don't see why the changes here can't be made configurable (and\n>>    perhaps you'd argue they should be on by default) via the ci-config\n>>    phase.\n>\n> I do not know if such a knob is feasible, though.\n\nIt would be rather trivial. Basically a matter of adding a \"if:\nneeds.ci-config.outputs.style == 'basic'\" to ci/print-test-failures.sh,\nand a corresponding flag passed down to ci/lib.sh to have it invoke\ntest-lib.sh with --github-workflow-markup or not.\n\nI.e. this series detects it's running in GitHub CI and optionally tells\ntest-lib.sh to emit different output, so to get the old output you'd\njust need to not opt-in to that.\n\nI think we can have our cake and eat it too though, so I don't think\nthere's any point in such a knob per-se. The only reason I'm suggesting\nit is because Johannes doesn't otherwise seem to want to address the\nsignificant CI UX slowdowns in this series.\n\nI do think the approach taken by this series is inherently limited in\nsolving that problem though, in a way that the approach outlined in [2]\nisn't.\n\nI.e. the problem is that we're throwing say ~30k-90k lines of raw CI\noutput at some GitHub JavaScript to format and present. Your browser\nneeds to download all the output, and then the browser needs to spin at\n100% CPU to present it to you.\n\nThe reason for that is that anything that tweaks the test-lib.sh output\nis something you need to consume *in its entirety*. I.e. when you have a\nsequence like:\n\n    ok 1 test one\n    ok 2 test two\n    not ok 3 test three\n    1..3\n\nYou don't know until the third test that you've had a failure. Short of\nteaching test-lib.sh even more complexity (e.g. pre-buffering its\n\"passing\" output) a UX layer needs to present all of it, and won't\nbenefit from a parsed representation of it.\n\nWhich is why I think adding other output formatters to test-lib.sh is a\ndead end approach to this problem.\n\nI mean, sure we could start parsing the new output emitted here, but\nthat doesn't make sense either.\n\nWe already run a full TAP parser over the output of the entire test\nsuite, which we can easily use to only print details about those tests\nthat failed[2]. We could also still have the full & raw output, but that\ncould be in some other tab (or \"stage\", just like\n\"ci/print-test-failures.sh\" is now.\n\nTo be fair that isn't quite as trivial in terms of patch count. In\nparticular we have edge cases currently where the TAP output isn't valid\ndue to bugs in test-lib.sh and/or tests, and can't combine it with the\n--verbose output. The demo at [2] is on top of some patches I've got\nlocally to fix all of that.\n\nBut I really think it's worth it to move a bit slower there & get it\nright rather than heading down the wrong direction of having another\nnot-quite-machine-readable output target.\n\nI.e. once it's machine readable & parsed we can present it however we\nlike, and can do *much better* output such as correlating trace output\nto the test source, and e.g. showing what specific line we failed\non. Right now all of that needs to be eyeballed & inferred from the\n\"--verbose -x\" output (which is often non-obvious & a pain, especially\nwhen the \"test_expect_success\" block calls helper functions).\n\n1. https://lore.kernel.org/git/cover-00.25-00000000000-20220221T143936Z-avarab@gmail.com/\n2. https://lore.kernel.org/git/220302.86mti87cj2.gmgdl@evledraar.gmail.com/\n"},{"id":"450832","messageId":"220309.86wnh3mivm.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"xmqqilspu1pp.fsf@gitster.g","subject":"Re: [PATCH 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-09T11:44:24Z","receivedAt":"2022-03-09T12:05:09Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Mar 07 2022, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n>>> One thing I forgot to mention was that when you expand a failing test it shows\n>>> the test script twice before the output e.g.\n>>>\n>>> Error: failed: t7527.35 Matrix[uc:false][fsm:true] enable fsmonitor\n>>> failure: t7527.35 Matrix[uc:false][fsm:true] enable fsmonitor\n>>>   \t\t\t\tgit config core.fsmonitor true &&\n>>>   \t\t\t\tgit fsmonitor--daemon start &&\n>>>   \t\t\t\tgit update-index --fsmonitor\n>>>\n>>>   expecting success of 7527.35 'Matrix[uc:false][fsm:true] enable fsmonitor':\n>>>   \t\t\t\tgit config core.fsmonitor true &&\n>>>   \t\t\t\tgit fsmonitor--daemon start &&\n>>>   \t\t\t\tgit update-index --fsmonitor\n>>>\n>>>  ++ git config core.fsmonitor true\n>>>  ++ git fsmonitor--daemon start\n>>>  ...\n>>>\n>>> I don't know how easy it would be to fix that so that we only show \"expecting\n>>> success of ...\" without the test being printed first\n>>\n>> It's not _super_ easy: right now, the patch series does not touch the code\n>\n> In other words, it is not a new issue introduced by this series, right?\n\nIt is a new issue in this series, specifically how\n\"finalize_test_case_output\" interacts with \"test_{ok,failure}_\" and\nfriends.\n\n>> The easiest workaround would probably to add a flag that suppresses the\n>> header `expecting success` in case we're running with the\n>> `--github-workflow-markup` option.\n>\n> If that is the case, let's leave it outside the series.\n>\n> If we do not have to hide the solution behind any option specific to\n> \"--github-workflow-markup\", then even users (like me) who reguarly\n> run \"cd t && sh ./t1234-a-particular-test.sh -i -v\" would benefit if\n> we no longer have to look at the duplicated test script in the\n> output.\n\nUnless you invoke it with --github-workflow-markup you won't see the\nduplication.\n\nI had some comments about inherent limitations in the approach in this\nseries vis-a-vis parsing markup after the fact[1]. But that really\ndoesn't seem to apply here. We're just printing the test source into the\n*.markup file twice for no particular reason, aren't we?\n\n*tests locally*\n\nHrm, so first this is a bug:\n    \n    $ ./t0002-gitfile.sh  --github-workflow-markup\n    FATAL: Unexpected exit with code 1\n    FATAL: Unexpected exit with code 1\n    \nSeems it wants --tee but doesn't declare it, this works:\n\n    $ rm -rf test-results/; ./t0002-gitfile.sh  --github-workflow-markup --tee; cat test-results/t0002-gitfile.markup\n\nIsn't this a matter of making finalize_test_case_output not print the\nfull $* (including the test source) for failures?\n\n1. https://lore.kernel.org/git/220309.861qzbnymn.gmgdl@evledraar.gmail.com/\n"},{"id":"450837","messageId":"nycvar.QRO.7.76.6.2203091320140.357@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"xmqqmti1u20m.fsf@gitster.g","subject":"Re: win+VS environment has \"cut\" but not \"paste\"?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-03-09T13:02:48Z","receivedAt":"2022-03-09T13:02:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Mon, 7 Mar 2022, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n> > I said that the current output is only useful to veterans. The output that\n> > hides the detailed log, under a separate job that is marked as\n> > non-failing.\n> >\n> > That's still as true as when I said it. :-)\n>\n> I think getting rid of the separate \"print failures\" CI step and\n> making it more discoverable how to reveal the details of failing\n> test step is a usability improvement.\n\nI'm so glad you're saying that! I was starting to doubt whether my caring\nabout getting rid of that `print failures` step was maybe misguided.\n\n> I am not Ævar, but I think what was questioned was the improvement\n> justifies multi dozens of seconds extra waiting time, which is a\n> usability dis-improvement.  I do not have a good answer to that\n> question.\n\nIt is definitely worrisome that we have to pay such a price. And if there\nwas a good answer how to improve that (without sacrificing the\ndiscoverability of the command trace corresponding to the test failure), I\nwould be more than just eager to hear it.\n\nI did consider generating a HTML-formatted report that would then be\nattached as a build artifact. But that would hide the relevant information\neven worse than a \"print failures\" step.\n\nMaybe I should just get rid of the grouping? But that _really_ helped me\nwhen I investigated the recent \"usage string updates\" vs \"FSMonitor\"\nproblem, because the test case boundaries were so much clearer.\n\nPlus, as far as I saw, GitHub workflow logs always scroll to the end of\nthe logs of the failing step, which would not help _at all_ here.\n\nSo I dunno.\n\n> I am probably nearing to be a veteran who knows when to brew my tea\n> in my work cycle, and waiting for an extra minute or two while\n> browsing CI output is not a problem for me.\n\n:-)\n\n> But new \"non-veteran\" users may not share that.  That is something a\n> bit worrying about the new UI.\n\nIndeed. My goal, after all, is to improve the experience of contributors,\nnot to make it harder.\n\nStill, given that you currently have to click quite a few times until you\nget to where you need to be, I have my doubts that what this patch series\ndoes is actually making things slower, measured in terms of the total time\nfrom seeing a failed build to being able to diagnose the cause by\ninspecting the command trace.\n\nCiao,\nDscho\n"},{"id":"450864","messageId":"nycvar.QRO.7.76.6.2203091404470.357@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"220307.86tuc9yc4b.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-03-09T13:20:23Z","receivedAt":"2022-03-09T13:20:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ævar,\n\nOn Mon, 7 Mar 2022, Ævar Arnfjörð Bjarmason wrote:\n\n> On Mon, Mar 07 2022, Johannes Schindelin wrote:\n>\n> > On Wed, 2 Mar 2022, Ævar Arnfjörð Bjarmason wrote:\n> >\n> >>\n> >> On Tue, Mar 01 2022, Johannes Schindelin via GitGitGadget wrote:\n> >>\n> >> > Changes since v1:\n> >> >\n> >> >  * In the patch that removed MAKE_TARGETS, a stale comment about that\n> >> >    variable is also removed.\n> >> >  * The comment about set -x has been adjusted because it no longer applies\n> >> >    as-is.\n> >> >  * The commit message of \"ci: make it easier to find failed tests' logs in\n> >> >    the GitHub workflow\" has been adjusted to motivate the improvement\n> >> >    better.\n> >>\n> >> Just briefly: Much of the feedback I had on v1 is still unanswered,\n> >\n> > Yes, because I got the sense that your feedback ignores the goal of making\n> > it easier to diagnose test failures.\n>\n> I think that's a rather strange conclusion given that I've submitted a\n> parallel series that makes some of those failures easier to diagnose\n> than the same changes in this series. I.e. the failures in build\n> v.s. test phases, not the individual test format output (but those are\n> orthagonal).\n\nI do not know what your parallel series implements, as I did not have the\ntime to read it yet (and it contains about double the number of patches of\nmy series, hopefully not intended to make it impossible for me to spare\nthe time to even taking a glimpse at it).\n\nAlso: I thought we had the rule of trying to be mindful of other\ncontributors and avoid interfering with patch series that are in flight?\nIt could be viewed as unnecessarily adversarial.\n\n> I think it's a fair summary of our differences that we're just placing\n> different values on UX responsiveness. I'm pretty sure there's some\n> amount of UX slowdown you'd consider unacceptable, no matter how much\n> the output was improved.\n>\n> Clearly we just use it differently.\n\nI would gladly trade my convenience in return for making it easier for\nothers to diagnose why their PR builds fail.\n\nAt the moment, the way our CI/PR builds present test failures very likely\nmakes every new contributor feel stupid for not knowing how to proceed.\nBut they are not stupid. The failure is not theirs. The fault lies\nsquarely with us, for making it so frigging hard.\n\n> >> or in the case of the performance issues I think just saying that this\n> >> output is aimed at non-long-time-contributors doesn't really justify the\n> >> large observed slowdowns.\n> >\n> > What good is a quickly-loading web site when it is less than useful?\n>\n> For all the flaws in the current output there are cases now where you\n> can click on a failure, see a summary of the 1-2 tests that failed, and\n> even find your way through the right place in the rather verbose raw log\n> output in 1/4 or 1/2 the time it takes the initial page on the new UX to\n> loda.\n\nI wonder where the hard data is that backs up these numbers.\n\nI do not have hard data, either, except for one: apart from you and Junio,\nI have yet to talk to any contributor who said \"oh yeah, I found the logs\nright away\" rather than things like \"when I finally figured out that the\nlogs were in `print-test-failures`, I had a chance to make sense of the\nfailures\" or even \"zOMG _that_ is where the logs are?\". And let me tell\nyou that I heard this from a lot of people. Way more than a mere two.\nFar, far more.\n\n> > I'd much rather have a slow-loading web site that gets me to where I need\n> > to be than a fast-loading one that leaves me as puzzled as before.\n>\n> I think it's clear that we're going to disagree on this point, but I'd\n> still think that:\n>\n>  * In a re-roll, you should amend these patches to clearly note that's a\n>    UX trade-off you're making, perhaps with rough before/after timings\n>    similar to the ones I've posted.\n>\n>    I.e. now those patches say nothing about the UX change resulting in\n>    UX that's *much* slower than before. Clearly noting that trade-off\n>    for reviewers is not the same as saying the trade-off can't be made.\n\nSure, I can do that.\n\n>  * I don't see why the changes here can't be made configurable (and\n>    perhaps you'd argue they should be on by default) via the ci-config\n>    phase.\n\nI do see why. If my goal is to unhide the logs by default, so that new\ncontributors can find them more easily, I will not hide that new behavior\nbehind a hard-to-find config option, an option that new contributors are\neven less likely to find. That would be highly counterproductive. If your\ngoal is to help new contributors, I am certain that you will agree.\n\nCiao,\nJohannes\n"},{"id":"450920","messageId":"xmqq35jqlxui.fsf@gitster.g","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2203091404470.357@tvgsbejvaqbjf.bet","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-09T19:39:17Z","receivedAt":"2022-03-09T19:39:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> I do not have hard data, either, except for one: apart from you and Junio,\n> I have yet to talk to any contributor who said \"oh yeah, I found the logs\n> right away\" rather than things like \"when I finally figured out that the\n> logs were in `print-test-failures`, I had a chance to make sense of the\n> failures\" or even \"zOMG _that_ is where the logs are?\". And let me tell\n> you that I heard this from a lot of people. Way more than a mere two.\n> Far, far more.\n\nStop counting me there.  I didn't find the logs right away, and I\nalready said that it is a good idea to eliminate the need to open\nthe thing other than the one that opens by default.\n"},{"id":"450925","messageId":"220309.86tuc6lwpj.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2203091404470.357@tvgsbejvaqbjf.bet","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-09T19:47:40Z","receivedAt":"2022-03-09T20:03:58Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Mar 09 2022, Johannes Schindelin wrote:\n\n> Hi Ævar,\n>\n> On Mon, 7 Mar 2022, Ævar Arnfjörð Bjarmason wrote:\n>\n>> On Mon, Mar 07 2022, Johannes Schindelin wrote:\n>>\n>> > On Wed, 2 Mar 2022, Ævar Arnfjörð Bjarmason wrote:\n>> >\n>> >>\n>> >> On Tue, Mar 01 2022, Johannes Schindelin via GitGitGadget wrote:\n>> >>\n>> >> > Changes since v1:\n>> >> >\n>> >> >  * In the patch that removed MAKE_TARGETS, a stale comment about that\n>> >> >    variable is also removed.\n>> >> >  * The comment about set -x has been adjusted because it no longer applies\n>> >> >    as-is.\n>> >> >  * The commit message of \"ci: make it easier to find failed tests' logs in\n>> >> >    the GitHub workflow\" has been adjusted to motivate the improvement\n>> >> >    better.\n>> >>\n>> >> Just briefly: Much of the feedback I had on v1 is still unanswered,\n>> >\n>> > Yes, because I got the sense that your feedback ignores the goal of making\n>> > it easier to diagnose test failures.\n>>\n>> I think that's a rather strange conclusion given that I've submitted a\n>> parallel series that makes some of those failures easier to diagnose\n>> than the same changes in this series. I.e. the failures in build\n>> v.s. test phases, not the individual test format output (but those are\n>> orthagonal).\n>\n> I do not know what your parallel series implements, as I did not have the\n> time to read it yet (and it contains about double the number of patches of\n> my series, hopefully not intended to make it impossible for me to spare\n> the time to even taking a glimpse at it).\n\nNo, I'm not arranging patches in such a way as to make them harder for\nyou to review specifically. I thought those changes made sense as a\nlogical progression.\n\n> Also: I thought we had the rule of trying to be mindful of other\n> contributors and avoid interfering with patch series that are in flight?\n> It could be viewed as unnecessarily adversarial.\n\nYou don't need to look at the whole thing, but in\nhttps://lore.kernel.org/git/cover-00.25-00000000000-20220221T143936Z-avarab@gmail.com/\nscroll down to \"The following compares CI output\" and compare:\n\n  master: https://github.com/avar/git/runs/5274251909?check_suite_focus=true\n  this: https://github.com/avar/git/runs/5274464670?check_suite_focus=true\n  js: https://github.com/avar/git/runs/5272239403?check_suite_focus=true\n\nI.e. for the build v.s. test \"grouping\" you're doing early in your\nseries we can get the same with a significantly negative instead of\npositive diffstat to .github & ci/, and it frees up the \"nested groups\"\nthat you note as a limitation in your 4/9 with another potential group\nlevel (your 4/9:\nhttps://lore.kernel.org/git/9333ba781b8240f704e739b00d274f8c3d887e39.1643050574.git.gitgitgadget@gmail.com/)\n\nSo it's not meant to be adversarial, but to help out this topic at large\nby showing that a constraint you ran up against is something we don't\nneed to be limited by, and it makes that part of the CI output better.\n\nI think posting working code to demonstrate that we can indeed do that\nis the most productive thing to do, talk being cheap & all that.\n\nSo yes, I agree that in general it's better to avoid conflicting topics\netc., but in a case where a topic proposes to add a significant amount\nof code & complexity to get to some desired end-state, it makes sense to\ndemonstrate with a patch or patches that we can get to the same\nend-state in some simpler way.\n\n>> I think it's a fair summary of our differences that we're just placing\n>> different values on UX responsiveness. I'm pretty sure there's some\n>> amount of UX slowdown you'd consider unacceptable, no matter how much\n>> the output was improved.\n>>\n>> Clearly we just use it differently.\n>\n> I would gladly trade my convenience in return for making it easier for\n> others to diagnose why their PR builds fail.\n>\n> At the moment, the way our CI/PR builds present test failures very likely\n> makes every new contributor feel stupid for not knowing how to proceed.\n> But they are not stupid. The failure is not theirs. The fault lies\n> squarely with us, for making it so frigging hard.\n\nI agree with you that it's relatively bad & could be improved. I don't\nhave much issue with the end result we're left with once the page\nactually loads at the end of this series, just the practicalities of how\nslow the resulting UX is.\n\n>> >> or in the case of the performance issues I think just saying that this\n>> >> output is aimed at non-long-time-contributors doesn't really justify the\n>> >> large observed slowdowns.\n>> >\n>> > What good is a quickly-loading web site when it is less than useful?\n>>\n>> For all the flaws in the current output there are cases now where you\n>> can click on a failure, see a summary of the 1-2 tests that failed, and\n>> even find your way through the right place in the rather verbose raw log\n>> output in 1/4 or 1/2 the time it takes the initial page on the new UX to\n>> loda.\n>\n> I wonder where the hard data is that backs up these numbers.\n\nI've posted some in several replies to this series,\ne.g. https://lore.kernel.org/git/220222.86tucr6kz5.gmgdl@evledraar.gmail.com/;\nHave you tried to reproduce some of those?\n\nI.e. the \"hard data\" is that usually takes me 10-20 seconds to go from a\nCI link to the summary output & opening the \"raw dump\" view now, and the\nsame page is taking about a minute to just load with the new UX.\n\n> [...]\n>> > I'd much rather have a slow-loading web site that gets me to where I need\n>> > to be than a fast-loading one that leaves me as puzzled as before.\n>>\n>> I think it's clear that we're going to disagree on this point, but I'd\n>> still think that:\n>>\n>>  * In a re-roll, you should amend these patches to clearly note that's a\n>>    UX trade-off you're making, perhaps with rough before/after timings\n>>    similar to the ones I've posted.\n>>\n>>    I.e. now those patches say nothing about the UX change resulting in\n>>    UX that's *much* slower than before. Clearly noting that trade-off\n>>    for reviewers is not the same as saying the trade-off can't be made.\n>\n> Sure, I can do that.\n>\n>>  * I don't see why the changes here can't be made configurable (and\n>>    perhaps you'd argue they should be on by default) via the ci-config\n>>    phase.\n>\n> I do see why. If my goal is to unhide the logs by default, so that new\n> contributors can find them more easily, I will not hide that new behavior\n> behind a hard-to-find config option, an option that new contributors are\n> even less likely to find. That would be highly counterproductive. If your\n> goal is to help new contributors, I am certain that you will agree.\n\nI meant that they could be on by default, but to relatively easily give\nus an out to A/B test the performance of new fancy rendering v.s. the\ndumb raw dump we have now.\n\nIf that's done via CI config it's a rather trivial matter of\ne.g. re-pushing \"master\" somewhere, whereas if it needs a patch/revert\non top...\n"},{"id":"451031","messageId":"220310.86o82dj02q.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2203091320140.357@tvgsbejvaqbjf.bet","subject":"Re: win+VS environment has \"cut\" but not \"paste\"?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-10T15:23:02Z","receivedAt":"2022-03-10T15:31:48Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Mar 09 2022, Johannes Schindelin wrote:\n\n> Hi Junio,\n>\n> On Mon, 7 Mar 2022, Junio C Hamano wrote:\n>\n>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>>\n>> > I said that the current output is only useful to veterans. The output that\n>> > hides the detailed log, under a separate job that is marked as\n>> > non-failing.\n>> >\n>> > That's still as true as when I said it. :-)\n>>\n>> I think getting rid of the separate \"print failures\" CI step and\n>> making it more discoverable how to reveal the details of failing\n>> test step is a usability improvement.\n>\n> I'm so glad you're saying that! I was starting to doubt whether my caring\n> about getting rid of that `print failures` step was maybe misguided.\n\nI don't think anyone's been maintaining that getting rid of it wouldn't\nbe ideal. I for one have just been commenting on issues in the proposed\nimplementation.\n\nI think we might still want to retain some such steps in the future,\ni.e. if we have a failure have subsequent steps that on failure() bump\nvarying levels of verbosity / raw logs etc., or even try re-running the\ntest in different ways (e.g. narrow it down with --run).\n\nBut the failure step you see when something fails should ideally have\nthe failure plus the relevant error, just as we do with compile errors.\n\n>> I am not Ævar, but I think what was questioned was the improvement\n>> justifies multi dozens of seconds extra waiting time, which is a\n>> usability dis-improvement.  I do not have a good answer to that\n>> question.\n>\n> It is definitely worrisome that we have to pay such a price. And if there\n> was a good answer how to improve that (without sacrificing the\n> discoverability of the command trace corresponding to the test failure), I\n> would be more than just eager to hear it.\n\nIsn't the answer to that what I suggested in [1]; I.e. the performance\nproblem being that we include N number of lines of the output that\n*didn't fail*, and that's what slows down showing the relevant output\nthat *did* fail.\n\nI.e. if say t3070-wildmatch.sh fails in a couple of tests we'd show a\n*lot* of lines between the relevant failing tests, let's just elide the\nnon-failing ones and show the output for the failing ones specifically.\n\n*Sometimes* (but very rarely) it's relevant to still look at the full\noutput, since the failure might be due to an earlier silent failure in a\nprevious test (or the state it left behind), but I think that's rare\nenough that the right thing to do is just to stick that in a subsequent\n\"verbose dump\" step or whatever.\n\n>> But new \"non-veteran\" users may not share that.  That is something a\n>> bit worrying about the new UI.\n>\n> Indeed. My goal, after all, is to improve the experience of contributors,\n> not to make it harder.\n>\n> Still, given that you currently have to click quite a few times until you\n> get to where you need to be, I have my doubts that what this patch series\n> does is actually making things slower, measured in terms of the total time\n> from seeing a failed build to being able to diagnose the cause by\n> inspecting the command trace.\n\nYes, but wouldn't the \"Test Summary Report\" in [1] be the best of both\nworlds[1] (with some minor changes to adapt it to the GitHub \"grouping\"\noutput, perhaps)?\n\nThen you'd always see the specific of the failing test at the end, if\nyou had N number of failures you might have a lot of output above that,\nbut even that we could always tweak with some smart heuristic. I.e. show\nverbose \"not ok\" output if failures <10, if 10..100 elide some for the\nraw log, if >100 just print \"this is completely screwed\" or whatever :)\n\n1. https://lore.kernel.org/git/220302.86mti87cj2.gmgdl@evledraar.gmail.com/\n"},{"id":"452243","messageId":"6b83bb83-32b9-20c9-fa02-c1c3170351c3@github.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Victoria Dye","fromEmail":"vdye@github.com","sentAt":"2022-03-25T00:48:26Z","receivedAt":"2022-03-25T00:48:38Z","isPatch":true,"sender":{"key":"vdye@github.com","avatar":"https://avatars.githubusercontent.com/u/3619353?v=4"},"body":"Johannes Schindelin via GitGitGadget wrote:\n> Changes since v1:\n> \n>  * In the patch that removed MAKE_TARGETS, a stale comment about that\n>    variable is also removed.\n>  * The comment about set -x has been adjusted because it no longer applies\n>    as-is.\n>  * The commit message of \"ci: make it easier to find failed tests' logs in\n>    the GitHub workflow\" has been adjusted to motivate the improvement\n>    better.\n> \n> \n> Background\n> ==========\n> \n> Recent patches intended to help readers figure out CI failures much quicker\n> than before. Unfortunately, they haven't been entirely positive for me. For\n> example, they broke the branch protections in Microsoft's fork of Git, where\n> we require Pull Requests to pass a certain set of Checks (which are\n> identified by their names) and therefore caused follow-up work.\n> \n> Using CI and in general making it easier for new contributors is an area I'm\n> passionate about, and one I'd like to see improved.\n> \n> \n> The current situation\n> =====================\n> \n> Let me walk you through the current experience when a PR build fails: I get\n> a notification mail that only says that a certain job failed. There's no\n> indication of which test failed (or was it the build?). I can click on a\n> link at it takes me to the workflow run. Once there, all it says is \"Process\n> completed with exit code 1\", or even \"code 2\". Sure, I can click on one of\n> the failed jobs. It even expands the failed step's log (collapsing the other\n> steps). And what do I see there?\n> \n> Let's look at an example of a failed linux-clang (ubuntu-latest) job\n> [https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true]:\n> \n> [...]\n> Test Summary Report\n> -------------------\n> t1092-sparse-checkout-compatibility.sh           (Wstat: 256 Tests: 53 Failed: 1)\n>   Failed test:  49\n>   Non-zero exit status: 1\n> t3701-add-interactive.sh                         (Wstat: 0 Tests: 71 Failed: 0)\n>   TODO passed:   45, 47\n> Files=957, Tests=25489, 645 wallclock secs ( 5.74 usr  1.56 sys + 866.28 cusr 364.34 csys = 1237.92 CPU)\n> Result: FAIL\n> make[1]: *** [Makefile:53: prove] Error 1\n> make[1]: Leaving directory '/home/runner/work/git/git/t'\n> make: *** [Makefile:3018: test] Error 2\n> \n> \n> That's it. I count myself lucky not to be a new contributor being faced with\n> something like this.\n> \n> Now, since I am active in the Git project for a couple of days or so, I can\n> make sense of the \"TODO passed\" label and know that for the purpose of\n> fixing the build failures, I need to ignore this, and that I need to focus\n> on the \"Failed test\" part instead.\n> \n> I also know that I do not have to get myself an ubuntu-latest box just to\n> reproduce the error, I do not even have to check out the code and run it\n> just to learn what that \"49\" means.\n> \n> I know, and I do not expect any new contributor, not even most seasoned\n> contributors to know, that I have to patiently collapse the \"Run\n> ci/run-build-and-tests.sh\" job's log, and instead expand the \"Run\n> ci/print-test-failures.sh\" job log (which did not fail and hence does not\n> draw any attention to it).\n> \n\nYou can count me as one of the ones that, until this series, had no idea\nthis information existed in the CI logs. And it definitely would have been\nhelpful in figuring out some of the OS-specific bugs I've run into in the\npast. :) \n\n> I know, and again: I do not expect many others to know this, that I then\n> have to click into the \"Search logs\" box (not the regular web browser's\n> search via Ctrl+F!) and type in \"not ok\" to find the log of the failed test\n> case (and this might still be a \"known broken\" one that is marked via\n> test_expect_failure and once again needs to be ignored).\n> \n> To be excessively clear: This is not a great experience!\n> \n> \n> Improved output\n> ===============\n> \n> Our previous Azure Pipelines-based CI builds had a much nicer UI, one that\n> even showed flaky tests, and trends e.g. how long the test cases ran. When I\n> ported Git's CI over to GitHub workflows (to make CI more accessible to new\n> contributors), I knew fully well that we would leave this very nice UI\n> behind, and I had hoped that we would get something similar back via new,\n> community-contributed GitHub Actions that can be used in GitHub workflows.\n> However, most likely because we use a home-grown test framework implemented\n> in opinionated POSIX shells scripts, that did not happen.\n> \n> So I had a look at what standards exist e.g. when testing PowerShell\n> modules, in the way of marking up their test output in GitHub workflows, and\n> I was not disappointed: GitHub workflows support \"grouping\" of output lines,\n> i.e. marking sections of the output as a group that is then collapsed by\n> default and can be expanded. And it is this feature I decided to use in this\n> patch series, along with GitHub workflows' commands to display errors or\n> notices that are also shown on the summary page of the workflow run. Now, in\n> addition to \"Process completed with exit code\" on the summary page, we also\n> read something like:\n> \n> ⊗ linux-gcc (ubuntu-latest)\n>    failed: t9800.20 submit from detached head\n> \n> \n> Even better, this message is a link, and following that, the reader is\n> presented with something like this\n> [https://github.com/dscho/git/runs/4840190622?check_suite_focus=true]:\n> \n> ⏵ Run ci/run-build-and-tests.sh\n> ⏵ CI setup\n>   + ln -s /home/runner/none/.prove t/.prove\n>   + run_tests=t\n>   + export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n>   + group Build make\n>   + set +x\n> ⏵ Build\n> ⏵ Run tests\n>   === Failed test: t9800-git-p4-basic ===\n> ⏵ ok: t9800.1 start p4d\n> ⏵ ok: t9800.2 add p4 files\n> ⏵ ok: t9800.3 basic git p4 clone\n> ⏵ ok: t9800.4 depot typo error\n> ⏵ ok: t9800.5 git p4 clone @all\n> ⏵ ok: t9800.6 git p4 sync uninitialized repo\n> ⏵ ok: t9800.7 git p4 sync new branch\n> ⏵ ok: t9800.8 clone two dirs\n> ⏵ ok: t9800.9 clone two dirs, @all\n> ⏵ ok: t9800.10 clone two dirs, @all, conflicting files\n> ⏵ ok: t9800.11 clone two dirs, each edited by submit, single git commit\n> ⏵ ok: t9800.12 clone using non-numeric revision ranges\n> ⏵ ok: t9800.13 clone with date range, excluding some changes\n> ⏵ ok: t9800.14 exit when p4 fails to produce marshaled output\n> ⏵ ok: t9800.15 exit gracefully for p4 server errors\n> ⏵ ok: t9800.16 clone --bare should make a bare repository\n> ⏵ ok: t9800.17 initial import time from top change time\n> ⏵ ok: t9800.18 unresolvable host in P4PORT should display error\n> ⏵ ok: t9800.19 run hook p4-pre-submit before submit\n>   Error: failed: t9800.20 submit from detached head\n> ⏵ failure: t9800.20 submit from detached head \n>   Error: failed: t9800.21 submit from worktree\n> ⏵ failure: t9800.21 submit from worktree \n>   === Failed test: t9801-git-p4-branch ===\n>   [...]\n> \n> \n> The \"Failed test:\" lines are colored in yellow to give a better visual clue\n> about the logs' structure, the \"Error:\" label is colored in red to draw the\n> attention to the important part of the log, and the \"⏵\" characters indicate\n> that part of the log is collapsed and can be expanded by clicking on it.\n> \n> To drill down, the reader merely needs to expand the (failed) test case's\n> log by clicking on it, and then study the log. If needed (e.g. when the test\n> case relies on side effects from previous test cases), the logs of preceding\n> test cases can be expanded as well. In this example, when expanding\n> t9800.20, it looks like this (for ease of reading, I cut a few chunks of\n> lines, indicated by \"[...]\"):\n> \n> [...]\n> ⏵ ok: t9800.19 run hook p4-pre-submit before submit\n>   Error: failed: t9800.20 submit from detached head\n> ⏷ failure: t9800.20 submit from detached head \n>       test_when_finished cleanup_git &&\n>       git p4 clone --dest=\"$git\" //depot &&\n>         (\n>           cd \"$git\" &&\n>           git checkout p4/master &&\n>           >detached_head_test &&\n>           git add detached_head_test &&\n>           git commit -m \"add detached_head\" &&\n>           git config git-p4.skipSubmitEdit true &&\n>           git p4 submit &&\n>             git p4 rebase &&\n>             git log p4/master | grep detached_head\n>         )\n>     [...]\n>     Depot paths: //depot/\n>     Import destination: refs/remotes/p4/master\n>     \n>     Importing revision 9 (100%)Perforce db files in '.' will be created if missing...\n>     Perforce db files in '.' will be created if missing...\n>     \n>     Traceback (most recent call last):\n>       File \"/home/runner/work/git/git/git-p4\", line 4455, in <module>\n>         main()\n>       File \"/home/runner/work/git/git/git-p4\", line 4449, in main\n>         if not cmd.run(args):\n>       File \"/home/runner/work/git/git/git-p4\", line 2590, in run\n>         rebase.rebase()\n>       File \"/home/runner/work/git/git/git-p4\", line 4121, in rebase\n>         if len(read_pipe(\"git diff-index HEAD --\")) > 0:\n>       File \"/home/runner/work/git/git/git-p4\", line 297, in read_pipe\n>         retcode, out, err = read_pipe_full(c, *k, **kw)\n>       File \"/home/runner/work/git/git/git-p4\", line 284, in read_pipe_full\n>         p = subprocess.Popen(\n>       File \"/usr/lib/python3.8/subprocess.py\", line 858, in __init__\n>         self._execute_child(args, executable, preexec_fn, close_fds,\n>       File \"/usr/lib/python3.8/subprocess.py\", line 1704, in _execute_child\n>         raise child_exception_type(errno_num, err_msg, err_filename)\n>     FileNotFoundError: [Errno 2] No such file or directory: 'git diff-index HEAD --'\n>     error: last command exited with $?=1\n>     + cleanup_git\n>     + retry_until_success rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + nr_tries_left=60\n>     + rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + test_path_is_missing /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + test 1 -ne 1\n>     + test -e /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + retry_until_success mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + nr_tries_left=60\n>     + mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n>     + exit 1\n>     + eval_ret=1\n>     + :\n>     not ok 20 - submit from detached head\n>     #    \n>     #        test_when_finished cleanup_git &&\n>     #        git p4 clone --dest=\"$git\" //depot &&\n>     #        (\n>     #            cd \"$git\" &&\n>     #            git checkout p4/master &&\n>     #            >detached_head_test &&\n>     #            git add detached_head_test &&\n>     #            git commit -m \"add detached_head\" &&\n>     #            git config git-p4.skipSubmitEdit true &&\n>     #            git p4 submit &&\n>     #            git p4 rebase &&\n>     #            git log p4/master | grep detached_head\n>     #        )\n>     #    \n>   Error: failed: t9800.21 submit from worktree\n>   [...]\n> \n> \n> Is this the best UI we can have for test failures in CI runs? I hope we can\n> do better. Having said that, this patch series presents a pretty good start,\n> and offers a basis for future improvements.\n> \n\nI think these are really valuable improvements over our current state, but I\nalso understand the concerns about performance elsewhere in this thread\n(it's really slow to load for me as well, and scrolling/expanding the log\ngroups can be a bit glitchy in my browser). That said, I think there are a\ncouple ways you could improve the load time without sacrificing the (very\nhelpful) improvements you've made to error log visibility. I experimented a\nbit (example result [1]) and came up with some things that may help:\n\n* group errors by test file, rather than by test case (to reduce\n  parsing/rendering time for lots of groups).\n* print the verbose logs only for the failed test cases (to massively cut\n  down on the size of the log, particularly when there's only a couple\n  failures in a test file with a lot of passing tests).\n* skip printing the full text of the test in 'finalize_test_case_output'\n  when creating the group, i.e., use '$1' instead of '$*' (in both passing\n  and failing tests, this information is already printed via some other\n  means).\n\nIf you wanted to make sure a user could still access the full failure logs\n(i.e., including the \"ok\" test results), you could print a link to the\nartifacts page as well - that way, all of the information we currently\nprovide to users can still be found somewhere.\n\n[1] https://github.com/vdye/git/runs/5666973267\n\n> Johannes Schindelin (9):\n>   ci: fix code style\n>   ci/run-build-and-tests: take a more high-level view\n>   ci: make it easier to find failed tests' logs in the GitHub workflow\n>   ci/run-build-and-tests: add some structure to the GitHub workflow\n>     output\n>   tests: refactor --write-junit-xml code\n>   test(junit): avoid line feeds in XML attributes\n>   ci: optionally mark up output in the GitHub workflow\n>   ci: use `--github-workflow-markup` in the GitHub workflow\n>   ci: call `finalize_test_case_output` a little later\n> \n\nThe organization of these commits makes the series a bit confusing to read,\nmainly due to the JUnit changes in the middle. Patches 5-6 don't appear to\nbe dependent on patches 1-4, so they could be moved to the beginning (after\npatch 1). With that change, I think this series would flow more smoothly:\n\"Cleanup/non-functional change\" -> \"JUnit XML improvements\" -> \"Log UX\nimprovements\".\n\n>  .github/workflows/main.yml           |  12 ---\n>  ci/lib.sh                            |  82 +++++++++++++++--\n>  ci/run-build-and-tests.sh            |  14 +--\n>  ci/run-test-slice.sh                 |   5 +-\n>  t/test-lib-functions.sh              |   4 +-\n>  t/test-lib-github-workflow-markup.sh |  50 ++++++++++\n>  t/test-lib-junit.sh                  | 132 +++++++++++++++++++++++++++\n>  t/test-lib.sh                        | 128 ++++----------------------\n>  8 files changed, 288 insertions(+), 139 deletions(-)\n>  create mode 100644 t/test-lib-github-workflow-markup.sh\n>  create mode 100644 t/test-lib-junit.sh\n> \n> \n> base-commit: af4e5f569bc89f356eb34a9373d7f82aca6faa8a\n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1117%2Fdscho%2Fuse-grouping-in-ci-v2\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1117/dscho/use-grouping-in-ci-v2\n> Pull-Request: https://github.com/gitgitgadget/git/pull/1117\n> \n> Range-diff vs v1:\n> \n>   1:  db08b07c37a =  1:  db08b07c37a ci: fix code style\n>   2:  d2ff51bb5da !  2:  42ff3e170bf ci/run-build-and-tests: take a more high-level view\n>      @@ ci/run-build-and-tests.sh: pedantic)\n>        \t;;\n>        esac\n>        \n>      - # Any new \"test\" targets should not go after this \"make\", but should\n>      - # adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n>      - # start running tests.\n>      +-# Any new \"test\" targets should not go after this \"make\", but should\n>      +-# adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n>      +-# start running tests.\n>       -make $MAKE_TARGETS\n>       +make\n>       +if test -n \"$run_tests\"\n>   3:  98891b0d3f7 !  3:  bbbe1623257 ci: make it easier to find failed tests' logs in the GitHub workflow\n>      @@ Metadata\n>        ## Commit message ##\n>           ci: make it easier to find failed tests' logs in the GitHub workflow\n>       \n>      +    When investigating a test failure, the time that matters most is the\n>      +    time it takes from getting aware of the failure to displaying the output\n>      +    of the failing test case.\n>      +\n>           You currently have to know a lot of implementation details when\n>           investigating test failures in the CI runs. The first step is easy: the\n>           failed job is marked quite clearly, but when opening it, the failed step\n>      @@ Commit message\n>           The actually interesting part is in the detailed log of said failed\n>           test script. But that log is shown in the CI run's step that runs\n>           `ci/print-test-failures.sh`. And that step is _not_ expanded in the web\n>      -    UI by default.\n>      +    UI by default. It is even marked as \"successful\", which makes it very\n>      +    easy to miss that there is useful information hidden in there.\n>       \n>           Let's help the reader by showing the failed tests' detailed logs in the\n>           step that is expanded automatically, i.e. directly after the test suite\n>   4:  9333ba781b8 !  4:  f72254a9ac6 ci/run-build-and-tests: add some structure to the GitHub workflow output\n>      @@ ci/lib.sh\n>       +\n>       +# Set 'exit on error' for all CI scripts to let the caller know that\n>       +# something went wrong.\n>      -+# Set tracing executed commands, primarily setting environment variables\n>      -+# and installing dependencies.\n>      ++#\n>      ++# We already enabled tracing executed commands earlier. This helps by showing\n>      ++# how # environment variables are set and and dependencies are installed.\n>       +set -e\n>       +\n>        skip_branch_tip_with_tag () {\n>      @@ ci/lib.sh: linux-leaks)\n>       +set -x\n>       \n>        ## ci/run-build-and-tests.sh ##\n>      -@@ ci/run-build-and-tests.sh: esac\n>      - # Any new \"test\" targets should not go after this \"make\", but should\n>      - # adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n>      - # start running tests.\n>      +@@ ci/run-build-and-tests.sh: pedantic)\n>      + \t;;\n>      + esac\n>      + \n>       -make\n>       +group Build make\n>        if test -n \"$run_tests\"\n>   5:  94dcbe1bc43 =  5:  9eda6574313 tests: refactor --write-junit-xml code\n>   6:  41230100091 =  6:  c8b240af749 test(junit): avoid line feeds in XML attributes\n>   7:  98b32630fcd =  7:  15f199e810e ci: optionally mark up output in the GitHub workflow\n>   8:  1a6bd1846bc =  8:  91ea54f36c5 ci: use `--github-workflow-markup` in the GitHub workflow\n>   9:  992b1575889 =  9:  be2a83f5da3 ci: call `finalize_test_case_output` a little later\n> \n\n"},{"id":"452258","messageId":"220325.864k3mmm2x.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"6b83bb83-32b9-20c9-fa02-c1c3170351c3@github.com","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-25T09:02:07Z","receivedAt":"2022-03-25T09:13:35Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Mar 24 2022, Victoria Dye wrote:\n\n> Johannes Schindelin via GitGitGadget wrote:\n> [...]\n>> Is this the best UI we can have for test failures in CI runs? I hope we can\n>> do better. Having said that, this patch series presents a pretty good start,\n>> and offers a basis for future improvements.\n>> \n>\n> I think these are really valuable improvements over our current state, but I\n> also understand the concerns about performance elsewhere in this thread\n> (it's really slow to load for me as well, and scrolling/expanding the log\n> groups can be a bit glitchy in my browser). That said, I think there are a\n> couple ways you could improve the load time without sacrificing the (very\n> helpful) improvements you've made to error log visibility. I experimented a\n> bit (example result [1]) and came up with some things that may help:\n>\n> * group errors by test file, rather than by test case (to reduce\n>   parsing/rendering time for lots of groups).\n> * print the verbose logs only for the failed test cases (to massively cut\n>   down on the size of the log, particularly when there's only a couple\n>   failures in a test file with a lot of passing tests).\n> * skip printing the full text of the test in 'finalize_test_case_output'\n>   when creating the group, i.e., use '$1' instead of '$*' (in both passing\n>   and failing tests, this information is already printed via some other\n>   means).\n>\n> If you wanted to make sure a user could still access the full failure logs\n> (i.e., including the \"ok\" test results), you could print a link to the\n> artifacts page as well - that way, all of the information we currently\n> provide to users can still be found somewhere.\n>\n> [1] https://github.com/vdye/git/runs/5666973267\n\nThanks a lot for trying to address those concerns.\n\nI took a look at this and it definitely performs better, although in\nthis case the overall output is ~3k lines.\n\nI'd be curious to see how it performs on some of the cases discussed in\nearlier threads of >~50k lines, although it looks like in this case that\nwould require failures to be really widespread in the test suite.\n\nI just looked at this briefly, but looking at the branch I see you\nremoved the \"checking known breakage of[...]\" etc. from the non-GitHub\nmarkdown output, I didn't spot how that was related/needed.\n\n>> Johannes Schindelin (9):\n>>   ci: fix code style\n>>   ci/run-build-and-tests: take a more high-level view\n>>   ci: make it easier to find failed tests' logs in the GitHub workflow\n>>   ci/run-build-and-tests: add some structure to the GitHub workflow\n>>     output\n>>   tests: refactor --write-junit-xml code\n>>   test(junit): avoid line feeds in XML attributes\n>>   ci: optionally mark up output in the GitHub workflow\n>>   ci: use `--github-workflow-markup` in the GitHub workflow\n>>   ci: call `finalize_test_case_output` a little later\n>> \n>\n> The organization of these commits makes the series a bit confusing to read,\n> mainly due to the JUnit changes in the middle. Patches 5-6 don't appear to\n> be dependent on patches 1-4, so they could be moved to the beginning (after\n> patch 1). With that change, I think this series would flow more smoothly:\n> \"Cleanup/non-functional change\" -> \"JUnit XML improvements\" -> \"Log UX\n> improvements\".\n\nHave you had a change to look at the approach my suggestion of an\nalternate approach to the early part of this series takes?:\nhttps://lore.kernel.org/git/cover-00.25-00000000000-20220221T143936Z-avarab@gmail.com/\n\nI.e. to not build up ci/lib.sh to know to group the \"build\" etc. within\nthe \"run-build-and-test\" step, but instead just to pull those to the\ntop-level by running separate build & test steps.\n\n"},{"id":"452377","messageId":"888aa48b-3e1c-9cb7-e51f-0adacaa45118@github.com","threadId":"57297","inReplyTo":"220325.864k3mmm2x.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Victoria Dye","fromEmail":"vdye@github.com","sentAt":"2022-03-25T18:38:18Z","receivedAt":"2022-03-25T19:39:43Z","isPatch":true,"sender":{"key":"vdye@github.com","avatar":"https://avatars.githubusercontent.com/u/3619353?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> \n> On Thu, Mar 24 2022, Victoria Dye wrote:\n> \n>> Johannes Schindelin via GitGitGadget wrote:\n>> [...]\n>>> Is this the best UI we can have for test failures in CI runs? I hope we can\n>>> do better. Having said that, this patch series presents a pretty good start,\n>>> and offers a basis for future improvements.\n>>>\n>>\n>> I think these are really valuable improvements over our current state, but I\n>> also understand the concerns about performance elsewhere in this thread\n>> (it's really slow to load for me as well, and scrolling/expanding the log\n>> groups can be a bit glitchy in my browser). That said, I think there are a\n>> couple ways you could improve the load time without sacrificing the (very\n>> helpful) improvements you've made to error log visibility. I experimented a\n>> bit (example result [1]) and came up with some things that may help:\n>>\n>> * group errors by test file, rather than by test case (to reduce\n>>   parsing/rendering time for lots of groups).\n>> * print the verbose logs only for the failed test cases (to massively cut\n>>   down on the size of the log, particularly when there's only a couple\n>>   failures in a test file with a lot of passing tests).\n>> * skip printing the full text of the test in 'finalize_test_case_output'\n>>   when creating the group, i.e., use '$1' instead of '$*' (in both passing\n>>   and failing tests, this information is already printed via some other\n>>   means).\n>>\n>> If you wanted to make sure a user could still access the full failure logs\n>> (i.e., including the \"ok\" test results), you could print a link to the\n>> artifacts page as well - that way, all of the information we currently\n>> provide to users can still be found somewhere.\n>>\n>> [1] https://github.com/vdye/git/runs/5666973267\n> \n> Thanks a lot for trying to address those concerns.\n> \n> I took a look at this and it definitely performs better, although in\n> this case the overall output is ~3k lines.\n> \n> I'd be curious to see how it performs on some of the cases discussed in\n> earlier threads of >~50k lines, although it looks like in this case that\n> would require failures to be really widespread in the test suite.\n> \n\nUnfortunately, I don't have a direct comparison to that (the longest I found\nelsewhere in the thread was ~33k lines [1], but those failures came from\nstrange interactions on the 'shears/seen' branch of Git for Windows that I\ncouldn't easily replicate). If it helps, though, here's a 1:1 comparison of\nmy \"experiment\" branch's forced test failures with and without the\noptimizations I tried (without optimization, the total log is ~28k lines):\n\nwithout optimization: https://github.com/vdye/git/runs/5696305589 with\noptimization: https://github.com/vdye/git/runs/5666973267\n\nSo it's definitely faster - it still takes a couple seconds to load, but not\nso long that my browser struggles with it (which was my main issue with the\noriginal approach).\n\n[1] https://github.com/dscho/git/runs/4840190622\n\n> I just looked at this briefly, but looking at the branch I see you\n> removed the \"checking known breakage of[...]\" etc. from the non-GitHub\n> markdown output, I didn't spot how that was related/needed.\n> \n\nIt was mostly just another attempt to cut down on extraneous output (since,\nif a test fails, the test definition is printed after the failure, so we\nwould end up with the same information twice). \n\nThat said, if that were to be incorporated here, it'd need to be smarter\nthan what I tried - my change removed it entirely from the '.out' logs, and\nit means that any test that *does* pass wouldn't have its test definition\nlogged anywhere (I think). The ideal situation would be the extraneous test\ndefinition is only removed from the '.markup' files, but that's probably a\nchange better saved for a future patch/series.\n\n>>> Johannes Schindelin (9):\n>>>   ci: fix code style\n>>>   ci/run-build-and-tests: take a more high-level view\n>>>   ci: make it easier to find failed tests' logs in the GitHub workflow\n>>>   ci/run-build-and-tests: add some structure to the GitHub workflow\n>>>     output\n>>>   tests: refactor --write-junit-xml code\n>>>   test(junit): avoid line feeds in XML attributes\n>>>   ci: optionally mark up output in the GitHub workflow\n>>>   ci: use `--github-workflow-markup` in the GitHub workflow\n>>>   ci: call `finalize_test_case_output` a little later\n>>>\n>>\n>> The organization of these commits makes the series a bit confusing to read,\n>> mainly due to the JUnit changes in the middle. Patches 5-6 don't appear to\n>> be dependent on patches 1-4, so they could be moved to the beginning (after\n>> patch 1). With that change, I think this series would flow more smoothly:\n>> \"Cleanup/non-functional change\" -> \"JUnit XML improvements\" -> \"Log UX\n>> improvements\".\n> \n> Have you had a change to look at the approach my suggestion of an\n> alternate approach to the early part of this series takes?:\n> https://lore.kernel.org/git/cover-00.25-00000000000-20220221T143936Z-avarab@gmail.com/\n> \n> I.e. to not build up ci/lib.sh to know to group the \"build\" etc. within\n> the \"run-build-and-test\" step, but instead just to pull those to the\n> top-level by running separate build & test steps.\n> \n\nI looked at it a while ago, but I actually had a similar issue following\nthat series as I did this one; it's difficult to tell what's cleanup, what's\nrefactoring unrelated to this series, and what's an explicit difference in\napproach compared with this series. \n\nRevisiting it now, I did the same thing I did with dscho's series: ran your\nbranch with some forced test failures and looked at the results [2]. Based\non that, there are a couple of helpful things I see in your series that\ncontribute to the same overarching goal as this dscho's:\n\n* Separating build & test into different steps.\n    * This makes it more immediately obvious to a user whether the issue was\n      a compiler error or a test failure. Since test failures can only even\n      happen if the compilation passes, this doesn't create (another)\n      situation where the relevant failure information is in a different\n      step than the auto-expanded failing one.\n* Separating 'lib.sh --build' and 'make' into different steps. \n    * I was initially unsure of the value of this (conceptually, wouldn't\n      they both be part of \"build\"?), but I eventually understood it to be\n      \"setup the environment for [build|test]\" followed by \"run the\n      [build|test]\". Since the main thing dscho's series is addressing is\n      information visibility, I like that this similarly \"unburies\" the\n      environment configuration at the beginning of build/test.\n\nThose changes are great (and they probably have some positive impact on load\ntimes). But as far as I can tell, nothing else in your series directly\naddresses the main problem dscho is fixing here, which is that the verbose\nfailure logs are effectively hidden from the user (unless you know exactly\nwhere to look). As a result, it doesn't really fit as a \"replacement\" to\nthis one for me. Honestly, my ideal \"final form\" of all of this may be a\ncombination of both series, having the CI steps:\n\n- setup build environment\n- run build (make)\n- setup test environment\n- run test (make test) & print failure logs\n\nYou can still pull the 'make' executions out of 'run-build-and-test.sh', but\nI think the \"& print failure logs\" part of the 'test' step (i.e., the added\n'|| handle_failed_tests') is the critical piece that, although it would slow\nthings down to some extent (and, of course, it's subjective where the \"too\nslow\" line is), it would relevant failure information a whole lot more\naccessible. That's the real \"value-add\" of this series for me, if only\nbecause I know it would have helped me a bunch of times in the past - I\nabsolutely believe it would similarly help new contributors in the future.\n\n[2] https://github.com/vdye/git/runs/5695895629\n"},{"id":"455709","messageId":"nycvar.QRO.7.76.6.2205212307090.352@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"6b83bb83-32b9-20c9-fa02-c1c3170351c3@github.com","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-05-21T21:42:58Z","receivedAt":"2022-05-21T21:43:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Victoria,\n\n[sorry for the long delay, I was being pulled into too many directions,\nbut am incredibly grateful for your fantastic investigation.]\n\nOn Thu, 24 Mar 2022, Victoria Dye wrote:\n\n> Johannes Schindelin via GitGitGadget wrote:\n> > Changes since v1:\n> >\n> >  * In the patch that removed MAKE_TARGETS, a stale comment about that\n> >    variable is also removed.\n> >  * The comment about set -x has been adjusted because it no longer applies\n> >    as-is.\n> >  * The commit message of \"ci: make it easier to find failed tests' logs in\n> >    the GitHub workflow\" has been adjusted to motivate the improvement\n> >    better.\n> >\n> >\n> > Background\n> > ==========\n> >\n> > Recent patches intended to help readers figure out CI failures much quicker\n> > than before. Unfortunately, they haven't been entirely positive for me. For\n> > example, they broke the branch protections in Microsoft's fork of Git, where\n> > we require Pull Requests to pass a certain set of Checks (which are\n> > identified by their names) and therefore caused follow-up work.\n> >\n> > Using CI and in general making it easier for new contributors is an area I'm\n> > passionate about, and one I'd like to see improved.\n> >\n> >\n> > The current situation\n> > =====================\n> >\n> > Let me walk you through the current experience when a PR build fails: I get\n> > a notification mail that only says that a certain job failed. There's no\n> > indication of which test failed (or was it the build?). I can click on a\n> > link at it takes me to the workflow run. Once there, all it says is \"Process\n> > completed with exit code 1\", or even \"code 2\". Sure, I can click on one of\n> > the failed jobs. It even expands the failed step's log (collapsing the other\n> > steps). And what do I see there?\n> >\n> > Let's look at an example of a failed linux-clang (ubuntu-latest) job\n> > [https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true]:\n> >\n> > [...]\n> > Test Summary Report\n> > -------------------\n> > t1092-sparse-checkout-compatibility.sh           (Wstat: 256 Tests: 53 Failed: 1)\n> >   Failed test:  49\n> >   Non-zero exit status: 1\n> > t3701-add-interactive.sh                         (Wstat: 0 Tests: 71 Failed: 0)\n> >   TODO passed:   45, 47\n> > Files=957, Tests=25489, 645 wallclock secs ( 5.74 usr  1.56 sys + 866.28 cusr 364.34 csys = 1237.92 CPU)\n> > Result: FAIL\n> > make[1]: *** [Makefile:53: prove] Error 1\n> > make[1]: Leaving directory '/home/runner/work/git/git/t'\n> > make: *** [Makefile:3018: test] Error 2\n> >\n> >\n> > That's it. I count myself lucky not to be a new contributor being faced with\n> > something like this.\n> >\n> > Now, since I am active in the Git project for a couple of days or so, I can\n> > make sense of the \"TODO passed\" label and know that for the purpose of\n> > fixing the build failures, I need to ignore this, and that I need to focus\n> > on the \"Failed test\" part instead.\n> >\n> > I also know that I do not have to get myself an ubuntu-latest box just to\n> > reproduce the error, I do not even have to check out the code and run it\n> > just to learn what that \"49\" means.\n> >\n> > I know, and I do not expect any new contributor, not even most seasoned\n> > contributors to know, that I have to patiently collapse the \"Run\n> > ci/run-build-and-tests.sh\" job's log, and instead expand the \"Run\n> > ci/print-test-failures.sh\" job log (which did not fail and hence does not\n> > draw any attention to it).\n> >\n>\n> You can count me as one of the ones that, until this series, had no idea\n> this information existed in the CI logs. And it definitely would have been\n> helpful in figuring out some of the OS-specific bugs I've run into in the\n> past. :)\n\nExcellent. I think I have enough accounts to consider it a universal truth\nthat our CI output _needs_ something like this here patch series.\n\n> > I know, and again: I do not expect many others to know this, that I then\n> > have to click into the \"Search logs\" box (not the regular web browser's\n> > search via Ctrl+F!) and type in \"not ok\" to find the log of the failed test\n> > case (and this might still be a \"known broken\" one that is marked via\n> > test_expect_failure and once again needs to be ignored).\n> >\n> > To be excessively clear: This is not a great experience!\n> >\n> >\n> > Improved output\n> > ===============\n> >\n> > Our previous Azure Pipelines-based CI builds had a much nicer UI, one that\n> > even showed flaky tests, and trends e.g. how long the test cases ran. When I\n> > ported Git's CI over to GitHub workflows (to make CI more accessible to new\n> > contributors), I knew fully well that we would leave this very nice UI\n> > behind, and I had hoped that we would get something similar back via new,\n> > community-contributed GitHub Actions that can be used in GitHub workflows.\n> > However, most likely because we use a home-grown test framework implemented\n> > in opinionated POSIX shells scripts, that did not happen.\n> >\n> > So I had a look at what standards exist e.g. when testing PowerShell\n> > modules, in the way of marking up their test output in GitHub workflows, and\n> > I was not disappointed: GitHub workflows support \"grouping\" of output lines,\n> > i.e. marking sections of the output as a group that is then collapsed by\n> > default and can be expanded. And it is this feature I decided to use in this\n> > patch series, along with GitHub workflows' commands to display errors or\n> > notices that are also shown on the summary page of the workflow run. Now, in\n> > addition to \"Process completed with exit code\" on the summary page, we also\n> > read something like:\n> >\n> > ⊗ linux-gcc (ubuntu-latest)\n> >    failed: t9800.20 submit from detached head\n> >\n> >\n> > Even better, this message is a link, and following that, the reader is\n> > presented with something like this\n> > [https://github.com/dscho/git/runs/4840190622?check_suite_focus=true]:\n> >\n> > ⏵ Run ci/run-build-and-tests.sh\n> > ⏵ CI setup\n> >   + ln -s /home/runner/none/.prove t/.prove\n> >   + run_tests=t\n> >   + export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n> >   + group Build make\n> >   + set +x\n> > ⏵ Build\n> > ⏵ Run tests\n> >   === Failed test: t9800-git-p4-basic ===\n> > ⏵ ok: t9800.1 start p4d\n> > ⏵ ok: t9800.2 add p4 files\n> > ⏵ ok: t9800.3 basic git p4 clone\n> > ⏵ ok: t9800.4 depot typo error\n> > ⏵ ok: t9800.5 git p4 clone @all\n> > ⏵ ok: t9800.6 git p4 sync uninitialized repo\n> > ⏵ ok: t9800.7 git p4 sync new branch\n> > ⏵ ok: t9800.8 clone two dirs\n> > ⏵ ok: t9800.9 clone two dirs, @all\n> > ⏵ ok: t9800.10 clone two dirs, @all, conflicting files\n> > ⏵ ok: t9800.11 clone two dirs, each edited by submit, single git commit\n> > ⏵ ok: t9800.12 clone using non-numeric revision ranges\n> > ⏵ ok: t9800.13 clone with date range, excluding some changes\n> > ⏵ ok: t9800.14 exit when p4 fails to produce marshaled output\n> > ⏵ ok: t9800.15 exit gracefully for p4 server errors\n> > ⏵ ok: t9800.16 clone --bare should make a bare repository\n> > ⏵ ok: t9800.17 initial import time from top change time\n> > ⏵ ok: t9800.18 unresolvable host in P4PORT should display error\n> > ⏵ ok: t9800.19 run hook p4-pre-submit before submit\n> >   Error: failed: t9800.20 submit from detached head\n> > ⏵ failure: t9800.20 submit from detached head\n> >   Error: failed: t9800.21 submit from worktree\n> > ⏵ failure: t9800.21 submit from worktree\n> >   === Failed test: t9801-git-p4-branch ===\n> >   [...]\n> >\n> >\n> > The \"Failed test:\" lines are colored in yellow to give a better visual clue\n> > about the logs' structure, the \"Error:\" label is colored in red to draw the\n> > attention to the important part of the log, and the \"⏵\" characters indicate\n> > that part of the log is collapsed and can be expanded by clicking on it.\n> >\n> > To drill down, the reader merely needs to expand the (failed) test case's\n> > log by clicking on it, and then study the log. If needed (e.g. when the test\n> > case relies on side effects from previous test cases), the logs of preceding\n> > test cases can be expanded as well. In this example, when expanding\n> > t9800.20, it looks like this (for ease of reading, I cut a few chunks of\n> > lines, indicated by \"[...]\"):\n> >\n> > [...]\n> > ⏵ ok: t9800.19 run hook p4-pre-submit before submit\n> >   Error: failed: t9800.20 submit from detached head\n> > ⏷ failure: t9800.20 submit from detached head\n> >       test_when_finished cleanup_git &&\n> >       git p4 clone --dest=\"$git\" //depot &&\n> >         (\n> >           cd \"$git\" &&\n> >           git checkout p4/master &&\n> >           >detached_head_test &&\n> >           git add detached_head_test &&\n> >           git commit -m \"add detached_head\" &&\n> >           git config git-p4.skipSubmitEdit true &&\n> >           git p4 submit &&\n> >             git p4 rebase &&\n> >             git log p4/master | grep detached_head\n> >         )\n> >     [...]\n> >     Depot paths: //depot/\n> >     Import destination: refs/remotes/p4/master\n> >\n> >     Importing revision 9 (100%)Perforce db files in '.' will be created if missing...\n> >     Perforce db files in '.' will be created if missing...\n> >\n> >     Traceback (most recent call last):\n> >       File \"/home/runner/work/git/git/git-p4\", line 4455, in <module>\n> >         main()\n> >       File \"/home/runner/work/git/git/git-p4\", line 4449, in main\n> >         if not cmd.run(args):\n> >       File \"/home/runner/work/git/git/git-p4\", line 2590, in run\n> >         rebase.rebase()\n> >       File \"/home/runner/work/git/git/git-p4\", line 4121, in rebase\n> >         if len(read_pipe(\"git diff-index HEAD --\")) > 0:\n> >       File \"/home/runner/work/git/git/git-p4\", line 297, in read_pipe\n> >         retcode, out, err = read_pipe_full(c, *k, **kw)\n> >       File \"/home/runner/work/git/git/git-p4\", line 284, in read_pipe_full\n> >         p = subprocess.Popen(\n> >       File \"/usr/lib/python3.8/subprocess.py\", line 858, in __init__\n> >         self._execute_child(args, executable, preexec_fn, close_fds,\n> >       File \"/usr/lib/python3.8/subprocess.py\", line 1704, in _execute_child\n> >         raise child_exception_type(errno_num, err_msg, err_filename)\n> >     FileNotFoundError: [Errno 2] No such file or directory: 'git diff-index HEAD --'\n> >     error: last command exited with $?=1\n> >     + cleanup_git\n> >     + retry_until_success rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n> >     + nr_tries_left=60\n> >     + rm -r /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n> >     + test_path_is_missing /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n> >     + test 1 -ne 1\n> >     + test -e /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n> >     + retry_until_success mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n> >     + nr_tries_left=60\n> >     + mkdir /home/runner/work/git/git/t/trash directory.t9800-git-p4-basic/git\n> >     + exit 1\n> >     + eval_ret=1\n> >     + :\n> >     not ok 20 - submit from detached head\n> >     #\n> >     #        test_when_finished cleanup_git &&\n> >     #        git p4 clone --dest=\"$git\" //depot &&\n> >     #        (\n> >     #            cd \"$git\" &&\n> >     #            git checkout p4/master &&\n> >     #            >detached_head_test &&\n> >     #            git add detached_head_test &&\n> >     #            git commit -m \"add detached_head\" &&\n> >     #            git config git-p4.skipSubmitEdit true &&\n> >     #            git p4 submit &&\n> >     #            git p4 rebase &&\n> >     #            git log p4/master | grep detached_head\n> >     #        )\n> >     #\n> >   Error: failed: t9800.21 submit from worktree\n> >   [...]\n> >\n> >\n> > Is this the best UI we can have for test failures in CI runs? I hope we can\n> > do better. Having said that, this patch series presents a pretty good start,\n> > and offers a basis for future improvements.\n> >\n>\n> I think these are really valuable improvements over our current state, but I\n> also understand the concerns about performance elsewhere in this thread\n> (it's really slow to load for me as well, and scrolling/expanding the log\n> groups can be a bit glitchy in my browser). That said, I think there are a\n> couple ways you could improve the load time without sacrificing the (very\n> helpful) improvements you've made to error log visibility. I experimented a\n> bit (example result [1]) and came up with some things that may help:\n>\n> * group errors by test file, rather than by test case (to reduce\n>   parsing/rendering time for lots of groups).\n\nI really would like to avoid that, based on my past experience with\ndiagnosing test failures. It is definitely helpful if the structure lets\nthe reader expand individual test cases.\n\n> * print the verbose logs only for the failed test cases (to massively cut\n>   down on the size of the log, particularly when there's only a couple\n>   failures in a test file with a lot of passing tests).\n\nThat's an amazingly simple trick to improve the speed by a ton, indeed.\nThank you for this splendid idea!\n\n> * skip printing the full text of the test in 'finalize_test_case_output'\n>   when creating the group, i.e., use '$1' instead of '$*' (in both passing\n>   and failing tests, this information is already printed via some other\n>   means).\n>\n> If you wanted to make sure a user could still access the full failure logs\n> (i.e., including the \"ok\" test results), you could print a link to the\n> artifacts page as well - that way, all of the information we currently\n> provide to users can still be found somewhere.\n\nThat's a good point, I added that hint to the output (the link is\nunfortunately not available at the time we print that advice).\n\n>\n> [1] https://github.com/vdye/git/runs/5666973267\n>\n> > Johannes Schindelin (9):\n> >   ci: fix code style\n> >   ci/run-build-and-tests: take a more high-level view\n> >   ci: make it easier to find failed tests' logs in the GitHub workflow\n> >   ci/run-build-and-tests: add some structure to the GitHub workflow\n> >     output\n> >   tests: refactor --write-junit-xml code\n> >   test(junit): avoid line feeds in XML attributes\n> >   ci: optionally mark up output in the GitHub workflow\n> >   ci: use `--github-workflow-markup` in the GitHub workflow\n> >   ci: call `finalize_test_case_output` a little later\n> >\n>\n> The organization of these commits makes the series a bit confusing to read,\n> mainly due to the JUnit changes in the middle. Patches 5-6 don't appear to\n> be dependent on patches 1-4, so they could be moved to the beginning (after\n> patch 1). With that change, I think this series would flow more smoothly:\n> \"Cleanup/non-functional change\" -> \"JUnit XML improvements\" -> \"Log UX\n> improvements\".\n\nGreat feedback! I changed the order as suggested.\n\nAgain, thank you so much for helping me improve the user experience of\nGit's CI/PR builds.\n\nCiao,\nDscho\n"},{"id":"455712","messageId":"68793fcec62dce83a972a055fee46f48cedd115a.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 01/12] ci: fix code style","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:45Z","receivedAt":"2022-05-21T22:19:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nIn b92cb86ea14 (travis-ci: check that all build artifacts are\n.gitignore-d, 2017-12-31), a function was introduced with a code style\nthat is different from the surrounding code: it added the opening curly\nbrace on its own line, when all the existing functions in the same file\ncuddle that brace on the same line as the function name.\n\nLet's make the code style consistent again.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/lib.sh | 3 +--\n 1 file changed, 1 insertion(+), 2 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 86e37da9bc5..d718f4e386d 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -69,8 +69,7 @@ skip_good_tree () {\n \texit 0\n }\n \n-check_unignored_build_artifacts ()\n-{\n+check_unignored_build_artifacts () {\n \t! git ls-files --other --exclude-standard --error-unmatch \\\n \t\t-- ':/*' 2>/dev/null ||\n \t{\n-- \ngitgitgadget\n\n"},{"id":"455713","messageId":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v2.git.1646130289.gitgitgadget@gmail.com","subject":"[PATCH v3 00/12] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:44Z","receivedAt":"2022-05-21T22:19:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Changes since v2:\n\n * Logs for successful test cases are no longer shown, which improves the\n   time to load pages (thanks Victoria!).\n * The preamble for each test case is no longer shown twice (thanks\n   Victoria!).\n * We now explicitly mention where the full logs can be found.\n * Some patches were reordered to make the story line of this patch series\n   more coherent.\n * Rebased onto main due resolve merge conflicts with\n   ab/test-tap-fix-for-immediate.\n\nI cannot thank Victoria enough for the thorough investigation; It was\nexactly what I had hoped for, and if I had not been pulled into too many\ndirections at once, I would have incorporated her suggestions and provided a\nnew iteration much earlier.\n\nIt might not be all bad that this iteration had to wait a little longer,\nthough: In the meantime, the errors on the summary page are now deep-linked\ninto the part of the logs where the corresponding error message was\ngenerated (just click on the job name above the error message).\n\nNote: I tried to add another patch that would turn GCC's compile errors into\nGitHub workflow commands\n[https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions]\nthat would list the error messages on the summary page. However, that would\nhave required piping the output of make through a sed call, which in turn\nwould have required set -o pipefail (which is not supported by all the\nshells that are used in our CI). I even dabbled with using process\nsubstitution, but that made things even worse: the sed process would\ncontinue outputting after make was finished and after the ::endgroup::\ncommand, meaning that the output was garbled. I'll probably continue\ninvestigating at some stage, but for now I'll call my time-boxed experiment\na wash.\n\nChanges since v1:\n\n * In the patch that removed MAKE_TARGETS, a stale comment about that\n   variable is also removed.\n * The comment about set -x has been adjusted because it no longer applies\n   as-is.\n * The commit message of \"ci: make it easier to find failed tests' logs in\n   the GitHub workflow\" has been adjusted to motivate the improvement\n   better.\n\n\nBackground\n==========\n\nUsing CI and in general making it easier for new contributors is an area I'm\npassionate about, and one I'd like to see improved.\n\n\nThe current situation\n=====================\n\nLet me walk you through the current experience when a PR build fails: I get\na notification mail that only says that a certain job failed. There's no\nindication of which test failed (or was it the build?). I can click on a\nlink at it takes me to the workflow run. Once there, all it says is \"Process\ncompleted with exit code 1\", or even \"code 2\". Sure, I can click on one of\nthe failed jobs. It even expands the failed step's log (collapsing the other\nsteps). And what do I see there?\n\nLet's look at an example of a failed linux-clang (ubuntu-latest) job\n[https://github.com/git-for-windows/git/runs/4822802185?check_suite_focus=true]:\n\n[...]\nTest Summary Report\n-------------------\nt1092-sparse-checkout-compatibility.sh           (Wstat: 256 Tests: 53 Failed: 1)\n  Failed test:  49\n  Non-zero exit status: 1\nt3701-add-interactive.sh                         (Wstat: 0 Tests: 71 Failed: 0)\n  TODO passed:   45, 47\nFiles=957, Tests=25489, 645 wallclock secs ( 5.74 usr  1.56 sys + 866.28 cusr 364.34 csys = 1237.92 CPU)\nResult: FAIL\nmake[1]: *** [Makefile:53: prove] Error 1\nmake[1]: Leaving directory '/home/runner/work/git/git/t'\nmake: *** [Makefile:3018: test] Error 2\n\n\nThat's it. I count myself lucky not to be a new contributor being faced with\nsomething like this.\n\nNow, since I am active in the Git project for a couple of days or so, I can\nmake sense of the \"TODO passed\" label and know that for the purpose of\nfixing the build failures, I need to ignore this, and that I need to focus\non the \"Failed test\" part instead.\n\nI also know that I do not have to get myself an ubuntu-latest box just to\nreproduce the error, I do not even have to check out the code and run it\njust to learn what that \"49\" means.\n\nI know, and I do not expect any new contributor, not even most seasoned\ncontributors to know, that I have to patiently collapse the \"Run\nci/run-build-and-tests.sh\" job's log, and instead expand the \"Run\nci/print-test-failures.sh\" job log (which did not fail and hence does not\ndraw any attention to it).\n\nI know, and again: I do not expect many others to know this, that I then\nhave to click into the \"Search logs\" box (not the regular web browser's\nsearch via Ctrl+F!) and type in \"not ok\" to find the log of the failed test\ncase (and this might still be a \"known broken\" one that is marked via\ntest_expect_failure and once again needs to be ignored).\n\nTo be excessively clear: This is not a great experience!\n\n\nImproved output\n===============\n\nOur previous Azure Pipelines-based CI builds had a much nicer UI, one that\neven showed flaky tests, and trends e.g. how long the test cases ran. When I\nported Git's CI over to GitHub workflows (to make CI more accessible to new\ncontributors), I knew fully well that we would leave this very nice UI\nbehind, and I had hoped that we would get something similar back via new,\ncommunity-contributed GitHub Actions that can be used in GitHub workflows.\nHowever, most likely because we use a home-grown test framework implemented\nin opinionated POSIX shells scripts, that did not happen.\n\nSo I had a look at what standards exist e.g. when testing PowerShell\nmodules, in the way of marking up their test output in GitHub workflows, and\nI was not disappointed: GitHub workflows support \"grouping\" of output lines,\ni.e. marking sections of the output as a group that is then collapsed by\ndefault and can be expanded. And it is this feature I've decided to use in\nthis patch series, along with GitHub workflows' commands to display errors\nor notices that are also shown on the summary page of the workflow run. Now,\nin addition to \"Process completed with exit code\" on the summary page, we\nalso read something like:\n\n⊗ linux-clang (ubuntu-latest)\n   failed: t3400.22 rebase --apply -q is quiet\n\n\nEven better, this message is a link, and following that, the reader is\npresented with something like this\n[https://github.com/dscho/git/runs/6539591442?check_suite_focus=true#step:4:2954]:\n\n[...]\n=== Failed test: t3420-rebase-autostash ===\nThe full logs are in the artifacts attached to this run.\nError: failed: t3420.12 rebase --apply: --quit\n⏵ failure: t3420.12 rebase --apply: --quit \nError: failed: t3420.13 rebase --apply: non-conflicting rebase, conflicting stash\n⏵ failure: t3420.13 rebase --apply: non-conflicting rebase, conflicting stash \nError: failed: t3420.14 rebase --apply: check output with conflicting stash\n⏵ failure: t3420.14 rebase --apply: check output with conflicting stash \nError: failed: t3420.23 rebase --merge: --quit\n⏵ failure: t3420.23 rebase --merge: --quit \nError: failed: t3420.24 rebase --merge: non-conflicting rebase, conflicting stash\n⏵ failure: t3420.24 rebase --merge: non-conflicting rebase, conflicting stash \nError: failed: t3420.25 rebase --merge: check output with conflicting stash\n⏵ failure: t3420.25 rebase --merge: check output with conflicting stash \nError: failed: t3420.34 rebase --interactive: --quit\n⏵ failure: t3420.34 rebase --interactive: --quit \nError: failed: t3420.35 rebase --interactive: non-conflicting rebase, conflicting stash\n⏵ failure: t3420.35 rebase --interactive: non-conflicting rebase, conflicting stash \nError: failed: t3420.36 rebase --interactive: check output with conflicting stash\n⏵ failure: t3420.36 rebase --interactive: check output with conflicting stash \nError: failed: t3420.39 autostash is saved on editor failure with conflict\n⏵ failure: t3420.39 autostash is saved on editor failure with conflict \n[...]\n\n\nThe \"Failed test:\" lines are colored in yellow to give a better visual clue\nabout the logs' structure, the \"Error:\" label is colored in red to draw the\nattention to the important part of the log, and the \"⏵\" characters indicate\nthat part of the log is collapsed and can be expanded by clicking on it.\n\nTo drill down, the reader merely needs to expand the test case's log by\nclicking on it, and then study the log. If needed (e.g. when the test case\nrelies on side effects from previous test cases), the logs of preceding test\ncases can be expanded as well. In case the full log is needed, including the\nsuccessful test cases, they are included in the artifacts that are attached\nto the CI/PR run.\n\nIs this the best UI we can have for test failures in CI runs? I hope we can\ndo better. Having said that, this patch series presents a pretty good start,\nand offers a basis for future improvements.\n\nJohannes Schindelin (11):\n  ci: fix code style\n  tests: refactor --write-junit-xml code\n  test(junit): avoid line feeds in XML attributes\n  ci/run-build-and-tests: take a more high-level view\n  ci: make it easier to find failed tests' logs in the GitHub workflow\n  ci/run-build-and-tests: add some structure to the GitHub workflow\n    output\n  ci: optionally mark up output in the GitHub workflow\n  ci(github): skip the logs of the successful test cases\n  ci: use `--github-workflow-markup` in the GitHub workflow\n  ci(github): mention where the full logs can be found\n  ci: call `finalize_test_case_output` a little later\n\nVictoria Dye (1):\n  ci(github): avoid printing test case preamble twice\n\n .github/workflows/main.yml           |  12 ---\n ci/lib.sh                            |  83 +++++++++++++++--\n ci/run-build-and-tests.sh            |  14 +--\n ci/run-test-slice.sh                 |   5 +-\n t/test-lib-functions.sh              |   6 +-\n t/test-lib-github-workflow-markup.sh |  56 ++++++++++++\n t/test-lib-junit.sh                  | 132 +++++++++++++++++++++++++++\n t/test-lib.sh                        | 128 ++++----------------------\n 8 files changed, 297 insertions(+), 139 deletions(-)\n create mode 100644 t/test-lib-github-workflow-markup.sh\n create mode 100644 t/test-lib-junit.sh\n\n\nbase-commit: f9b95943b68b6b8ca5a6072f50a08411c6449b55\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1117%2Fdscho%2Fuse-grouping-in-ci-v3\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1117/dscho/use-grouping-in-ci-v3\nPull-Request: https://github.com/gitgitgadget/git/pull/1117\n\nRange-diff vs v2:\n\n  1:  db08b07c37a =  1:  68793fcec62 ci: fix code style\n  5:  9eda6574313 =  2:  cbf476e4e98 tests: refactor --write-junit-xml code\n  6:  c8b240af749 =  3:  30ccd602108 test(junit): avoid line feeds in XML attributes\n  2:  42ff3e170bf =  4:  8f5b112bd08 ci/run-build-and-tests: take a more high-level view\n  3:  bbbe1623257 !  5:  417f702a245 ci: make it easier to find failed tests' logs in the GitHub workflow\n     @@ ci/lib.sh: check_unignored_build_artifacts () {\n       \n      @@ ci/lib.sh: then\n       \tCI_JOB_ID=\"$GITHUB_RUN_ID\"\n     - \tCC=\"${CC:-gcc}\"\n     + \tCC=\"${CC_PACKAGE:-${CC:-gcc}}\"\n       \tDONT_SKIP_TAGS=t\n      +\thandle_failed_tests () {\n      +\t\tmkdir -p t/failed-test-artifacts\n  4:  f72254a9ac6 =  6:  7d2284314ef ci/run-build-and-tests: add some structure to the GitHub workflow output\n  7:  15f199e810e =  7:  98059b94a88 ci: optionally mark up output in the GitHub workflow\n  -:  ----------- >  8:  d3db5252fb8 ci(github): skip the logs of the successful test cases\n  -:  ----------- >  9:  51573ef6c54 ci(github): avoid printing test case preamble twice\n  8:  91ea54f36c5 = 10:  7f921ffef12 ci: use `--github-workflow-markup` in the GitHub workflow\n  -:  ----------- > 11:  370b08d3a11 ci(github): mention where the full logs can be found\n  9:  be2a83f5da3 ! 12:  fe355a6f03b ci: call `finalize_test_case_output` a little later\n     @@ t/test-lib.sh: trap '{ code=$?; set +x; } 2>/dev/null; exit $code' INT TERM HUP\n       \ttest_failure=$(($test_failure + 1))\n       \tsay_color error \"not ok $test_count - $1\"\n       \tshift\n     - \tprintf '%s\\n' \"$*\" | sed -e 's/^/#\t/'\n     - \ttest \"$immediate\" = \"\" || _error_exit\n     +@@ t/test-lib.sh: test_failure_ () {\n     + \t\tsay_color error \"1..$test_count\"\n     + \t\t_error_exit\n     + \tfi\n      +\tfinalize_test_case_output failure \"$failure_label\" \"$@\"\n       }\n       \n\n-- \ngitgitgadget\n"},{"id":"455714","messageId":"cbf476e4e988cd24ed42fd6f5ddaa7840a33583b.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 02/12] tests: refactor --write-junit-xml code","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:46Z","receivedAt":"2022-05-21T22:19:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nThe code writing JUnit XML is interspersed directly with all the code in\n`t/test-lib.sh`, and it is therefore not only ill-separated, but\nintroducing yet another output format would make the situation even\nworse.\n\nLet's introduce an abstraction layer by hiding the JUnit XML code behind\nfour new functions that are supposed to be called before and after each\ntest and test case.\n\nThis is not just an academic exercise, refactoring for refactoring's\nsake. We _actually_ want to introduce such a new output format, to\nmake it substantially easier to diagnose test failures in our GitHub\nworkflow, therefore we do need this refactoring.\n\nThis commit is best viewed with `git show --color-moved\n--color-moved-ws=allow-indentation-change <commit>`.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib-junit.sh | 126 ++++++++++++++++++++++++++++++++++++++++++++\n t/test-lib.sh       | 124 ++++++-------------------------------------\n 2 files changed, 142 insertions(+), 108 deletions(-)\n create mode 100644 t/test-lib-junit.sh\n\ndiff --git a/t/test-lib-junit.sh b/t/test-lib-junit.sh\nnew file mode 100644\nindex 00000000000..9d55d74d764\n--- /dev/null\n+++ b/t/test-lib-junit.sh\n@@ -0,0 +1,126 @@\n+# Library of functions to format test scripts' output in JUnit XML\n+# format, to support Git's test suite result to be presented in an\n+# easily digestible way on Azure Pipelines.\n+#\n+# Copyright (c) 2022 Johannes Schindelin\n+#\n+# This program is free software: you can redistribute it and/or modify\n+# it under the terms of the GNU General Public License as published by\n+# the Free Software Foundation, either version 2 of the License, or\n+# (at your option) any later version.\n+#\n+# This program is distributed in the hope that it will be useful,\n+# but WITHOUT ANY WARRANTY; without even the implied warranty of\n+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n+# GNU General Public License for more details.\n+#\n+# You should have received a copy of the GNU General Public License\n+# along with this program.  If not, see http://www.gnu.org/licenses/ .\n+#\n+# The idea is for `test-lib.sh` to source this file when the user asks\n+# for JUnit XML; these functions will then override (empty) functions\n+# that are are called at the appropriate times during the test runs.\n+\n+start_test_output () {\n+\tjunit_xml_dir=\"$TEST_OUTPUT_DIRECTORY/out\"\n+\tmkdir -p \"$junit_xml_dir\"\n+\tjunit_xml_base=${1##*/}\n+\tjunit_xml_path=\"$junit_xml_dir/TEST-${junit_xml_base%.sh}.xml\"\n+\tjunit_attrs=\"name=\\\"${junit_xml_base%.sh}\\\"\"\n+\tjunit_attrs=\"$junit_attrs timestamp=\\\"$(TZ=UTC \\\n+\t\tdate +%Y-%m-%dT%H:%M:%S)\\\"\"\n+\twrite_junit_xml --truncate \"<testsuites>\" \"  <testsuite $junit_attrs>\"\n+\tjunit_suite_start=$(test-tool date getnanos)\n+\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n+\tthen\n+\t\tGIT_TEST_TEE_OFFSET=0\n+\tfi\n+}\n+\n+start_test_case_output () {\n+\tjunit_start=$(test-tool date getnanos)\n+}\n+\n+finalize_test_case_output () {\n+\ttest_case_result=$1\n+\tshift\n+\tcase \"$test_case_result\" in\n+\tok)\n+\t\tset \"$*\"\n+\t\t;;\n+\tfailure)\n+\t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n+\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \"$1\")\\\">\"\n+\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \\\n+\t\t\t\"$(if test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n+\t\t\t   then\n+\t\t\t\ttest-tool path-utils skip-n-bytes \\\n+\t\t\t\t\t\"$GIT_TEST_TEE_OUTPUT_FILE\" $GIT_TEST_TEE_OFFSET\n+\t\t\t   else\n+\t\t\t\tprintf '%s\\n' \"$@\" | sed 1d\n+\t\t\t   fi)\")\"\n+\t\tjunit_insert=\"$junit_insert</failure>\"\n+\t\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n+\t\tthen\n+\t\t\tjunit_insert=\"$junit_insert<system-err>$(xml_attr_encode \\\n+\t\t\t\t\"$(cat \"$GIT_TEST_TEE_OUTPUT_FILE\")\")</system-err>\"\n+\t\tfi\n+\t\tset \"$1\" \"      $junit_insert\"\n+\t\t;;\n+\tfixed)\n+\t\tset \"$* (breakage fixed)\"\n+\t\t;;\n+\tbroken)\n+\t\tset \"$* (known breakage)\"\n+\t\t;;\n+\tskip)\n+\t\tmessage=\"$(xml_attr_encode \"$skipped_reason\")\"\n+\t\tset \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n+\t\t;;\n+\tesac\n+\n+\tjunit_attrs=\"name=\\\"$(xml_attr_encode \"$this_test.$test_count $1\")\\\"\"\n+\tshift\n+\tjunit_attrs=\"$junit_attrs classname=\\\"$this_test\\\"\"\n+\tjunit_attrs=\"$junit_attrs time=\\\"$(test-tool \\\n+\t\tdate getnanos $junit_start)\\\"\"\n+\twrite_junit_xml \"$(printf '%s\\n' \\\n+\t\t\"    <testcase $junit_attrs>\" \"$@\" \"    </testcase>\")\"\n+\tjunit_have_testcase=t\n+}\n+\n+finalize_test_output () {\n+\tif test -n \"$junit_xml_path\"\n+\tthen\n+\t\ttest -n \"$junit_have_testcase\" || {\n+\t\t\tjunit_start=$(test-tool date getnanos)\n+\t\t\twrite_junit_xml_testcase \"all tests skipped\"\n+\t\t}\n+\n+\t\t# adjust the overall time\n+\t\tjunit_time=$(test-tool date getnanos $junit_suite_start)\n+\t\tsed -e \"s/\\(<testsuite.*\\) time=\\\"[^\\\"]*\\\"/\\1/\" \\\n+\t\t\t-e \"s/<testsuite [^>]*/& time=\\\"$junit_time\\\"/\" \\\n+\t\t\t-e '/^ *<\\/testsuite/d' \\\n+\t\t\t<\"$junit_xml_path\" >\"$junit_xml_path.new\"\n+\t\tmv \"$junit_xml_path.new\" \"$junit_xml_path\"\n+\n+\t\twrite_junit_xml \"  </testsuite>\" \"</testsuites>\"\n+\t\twrite_junit_xml=\n+\tfi\n+}\n+\n+write_junit_xml () {\n+\tcase \"$1\" in\n+\t--truncate)\n+\t\t>\"$junit_xml_path\"\n+\t\tjunit_have_testcase=\n+\t\tshift\n+\t\t;;\n+\tesac\n+\tprintf '%s\\n' \"$@\" >>\"$junit_xml_path\"\n+}\n+\n+xml_attr_encode () {\n+\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n+}\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex f09e8f3efce..bdb11e28eea 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -137,6 +137,12 @@ mark_option_requires_arg () {\n \tstore_arg_to=$2\n }\n \n+# These functions can be overridden e.g. to output JUnit XML\n+start_test_output () { :; }\n+start_test_case_output () { :; }\n+finalize_test_case_output () { :; }\n+finalize_test_output () { :; }\n+\n parse_option () {\n \tlocal opt=\"$1\"\n \n@@ -196,7 +202,7 @@ parse_option () {\n \t\ttee=t\n \t\t;;\n \t--write-junit-xml)\n-\t\twrite_junit_xml=t\n+\t\t. \"$TEST_DIRECTORY/test-lib-junit.sh\"\n \t\t;;\n \t--stress)\n \t\tstress=t ;;\n@@ -664,7 +670,7 @@ exec 6<&0\n exec 7>&2\n \n _error_exit () {\n-\tfinalize_junit_xml\n+\tfinalize_test_output\n \tGIT_EXIT_OK=t\n \texit 1\n }\n@@ -774,35 +780,13 @@ trap '{ code=$?; set +x; } 2>/dev/null; exit $code' INT TERM HUP\n # the test_expect_* functions instead.\n \n test_ok_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\twrite_junit_xml_testcase \"$*\"\n-\tfi\n+\tfinalize_test_case_output ok \"$@\"\n \ttest_success=$(($test_success + 1))\n \tsay_color \"\" \"ok $test_count - $@\"\n }\n \n test_failure_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n-\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \"$1\")\\\">\"\n-\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \\\n-\t\t\t\"$(if test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n-\t\t\t   then\n-\t\t\t\ttest-tool path-utils skip-n-bytes \\\n-\t\t\t\t\t\"$GIT_TEST_TEE_OUTPUT_FILE\" $GIT_TEST_TEE_OFFSET\n-\t\t\t   else\n-\t\t\t\tprintf '%s\\n' \"$@\" | sed 1d\n-\t\t\t   fi)\")\"\n-\t\tjunit_insert=\"$junit_insert</failure>\"\n-\t\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n-\t\tthen\n-\t\t\tjunit_insert=\"$junit_insert<system-err>$(xml_attr_encode \\\n-\t\t\t\t\"$(cat \"$GIT_TEST_TEE_OUTPUT_FILE\")\")</system-err>\"\n-\t\tfi\n-\t\twrite_junit_xml_testcase \"$1\" \"      $junit_insert\"\n-\tfi\n+\tfinalize_test_case_output failure \"$@\"\n \ttest_failure=$(($test_failure + 1))\n \tsay_color error \"not ok $test_count - $1\"\n \tshift\n@@ -815,19 +799,13 @@ test_failure_ () {\n }\n \n test_known_broken_ok_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\twrite_junit_xml_testcase \"$* (breakage fixed)\"\n-\tfi\n+\tfinalize_test_case_output fixed \"$@\"\n \ttest_fixed=$(($test_fixed+1))\n \tsay_color error \"ok $test_count - $@ # TODO known breakage vanished\"\n }\n \n test_known_broken_failure_ () {\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\twrite_junit_xml_testcase \"$* (known breakage)\"\n-\tfi\n+\tfinalize_test_case_output broken \"$@\"\n \ttest_broken=$(($test_broken+1))\n \tsay_color warn \"not ok $test_count - $@ # TODO known breakage\"\n }\n@@ -1104,10 +1082,7 @@ test_start_ () {\n \ttest_count=$(($test_count+1))\n \tmaybe_setup_verbose\n \tmaybe_setup_valgrind\n-\tif test -n \"$write_junit_xml\"\n-\tthen\n-\t\tjunit_start=$(test-tool date getnanos)\n-\tfi\n+\tstart_test_case_output\n }\n \n test_finish_ () {\n@@ -1158,12 +1133,7 @@ test_skip () {\n \n \tcase \"$to_skip\" in\n \tt)\n-\t\tif test -n \"$write_junit_xml\"\n-\t\tthen\n-\t\t\tmessage=\"$(xml_attr_encode \"$skipped_reason\")\"\n-\t\t\twrite_junit_xml_testcase \"$1\" \\\n-\t\t\t\t\"      <skipped message=\\\"$message\\\" />\"\n-\t\tfi\n+\t\tfinalize_test_case_output skip \"$@\"\n \n \t\tsay_color skip \"ok $test_count # skip $1 ($skipped_reason)\"\n \t\t: true\n@@ -1179,53 +1149,6 @@ test_at_end_hook_ () {\n \t:\n }\n \n-write_junit_xml () {\n-\tcase \"$1\" in\n-\t--truncate)\n-\t\t>\"$junit_xml_path\"\n-\t\tjunit_have_testcase=\n-\t\tshift\n-\t\t;;\n-\tesac\n-\tprintf '%s\\n' \"$@\" >>\"$junit_xml_path\"\n-}\n-\n-xml_attr_encode () {\n-\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n-}\n-\n-write_junit_xml_testcase () {\n-\tjunit_attrs=\"name=\\\"$(xml_attr_encode \"$this_test.$test_count $1\")\\\"\"\n-\tshift\n-\tjunit_attrs=\"$junit_attrs classname=\\\"$this_test\\\"\"\n-\tjunit_attrs=\"$junit_attrs time=\\\"$(test-tool \\\n-\t\tdate getnanos $junit_start)\\\"\"\n-\twrite_junit_xml \"$(printf '%s\\n' \\\n-\t\t\"    <testcase $junit_attrs>\" \"$@\" \"    </testcase>\")\"\n-\tjunit_have_testcase=t\n-}\n-\n-finalize_junit_xml () {\n-\tif test -n \"$write_junit_xml\" && test -n \"$junit_xml_path\"\n-\tthen\n-\t\ttest -n \"$junit_have_testcase\" || {\n-\t\t\tjunit_start=$(test-tool date getnanos)\n-\t\t\twrite_junit_xml_testcase \"all tests skipped\"\n-\t\t}\n-\n-\t\t# adjust the overall time\n-\t\tjunit_time=$(test-tool date getnanos $junit_suite_start)\n-\t\tsed -e \"s/\\(<testsuite.*\\) time=\\\"[^\\\"]*\\\"/\\1/\" \\\n-\t\t\t-e \"s/<testsuite [^>]*/& time=\\\"$junit_time\\\"/\" \\\n-\t\t\t-e '/^ *<\\/testsuite/d' \\\n-\t\t\t<\"$junit_xml_path\" >\"$junit_xml_path.new\"\n-\t\tmv \"$junit_xml_path.new\" \"$junit_xml_path\"\n-\n-\t\twrite_junit_xml \"  </testsuite>\" \"</testsuites>\"\n-\t\twrite_junit_xml=\n-\tfi\n-}\n-\n test_atexit_cleanup=:\n test_atexit_handler () {\n \t# In a succeeding test script 'test_atexit_handler' is invoked\n@@ -1248,7 +1171,7 @@ test_done () {\n \t# removed, so the commands can access pidfiles and socket files.\n \ttest_atexit_handler\n \n-\tfinalize_junit_xml\n+\tfinalize_test_output\n \n \tif test -z \"$HARNESS_ACTIVE\"\n \tthen\n@@ -1539,22 +1462,7 @@ fi\n # in subprocesses like git equals our $PWD (for pathname comparisons).\n cd -P \"$TRASH_DIRECTORY\" || exit 1\n \n-if test -n \"$write_junit_xml\"\n-then\n-\tjunit_xml_dir=\"$TEST_OUTPUT_DIRECTORY/out\"\n-\tmkdir -p \"$junit_xml_dir\"\n-\tjunit_xml_base=${0##*/}\n-\tjunit_xml_path=\"$junit_xml_dir/TEST-${junit_xml_base%.sh}.xml\"\n-\tjunit_attrs=\"name=\\\"${junit_xml_base%.sh}\\\"\"\n-\tjunit_attrs=\"$junit_attrs timestamp=\\\"$(TZ=UTC \\\n-\t\tdate +%Y-%m-%dT%H:%M:%S)\\\"\"\n-\twrite_junit_xml --truncate \"<testsuites>\" \"  <testsuite $junit_attrs>\"\n-\tjunit_suite_start=$(test-tool date getnanos)\n-\tif test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n-\tthen\n-\t\tGIT_TEST_TEE_OFFSET=0\n-\tfi\n-fi\n+start_test_output \"$0\"\n \n # Convenience\n # A regexp to match 5 and 35 hexdigits\n-- \ngitgitgadget\n\n"},{"id":"455715","messageId":"30ccd602108fea74d64a5b81e6665fcc7efb6f0a.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 03/12] test(junit): avoid line feeds in XML attributes","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:47Z","receivedAt":"2022-05-21T22:19:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nIn the test case's output, we do want newline characters, but in the XML\nattributes we do not want them.\n\nHowever, the `xml_attr_encode` function always adds a Line Feed at the\nend (which are then encoded as `&#x0a;`, even for XML attributes.\n\nThis seems not to faze Azure Pipelines' XML parser, but it still is\nincorrect, so let's fix it.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib-junit.sh | 14 ++++++++++----\n 1 file changed, 10 insertions(+), 4 deletions(-)\n\ndiff --git a/t/test-lib-junit.sh b/t/test-lib-junit.sh\nindex 9d55d74d764..c959183c7e2 100644\n--- a/t/test-lib-junit.sh\n+++ b/t/test-lib-junit.sh\n@@ -50,7 +50,7 @@ finalize_test_case_output () {\n \t\t;;\n \tfailure)\n \t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n-\t\tjunit_insert=\"$junit_insert $(xml_attr_encode \"$1\")\\\">\"\n+\t\tjunit_insert=\"$junit_insert $(xml_attr_encode --no-lf \"$1\")\\\">\"\n \t\tjunit_insert=\"$junit_insert $(xml_attr_encode \\\n \t\t\t\"$(if test -n \"$GIT_TEST_TEE_OUTPUT_FILE\"\n \t\t\t   then\n@@ -74,12 +74,12 @@ finalize_test_case_output () {\n \t\tset \"$* (known breakage)\"\n \t\t;;\n \tskip)\n-\t\tmessage=\"$(xml_attr_encode \"$skipped_reason\")\"\n+\t\tmessage=\"$(xml_attr_encode --no-lf \"$skipped_reason\")\"\n \t\tset \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n \t\t;;\n \tesac\n \n-\tjunit_attrs=\"name=\\\"$(xml_attr_encode \"$this_test.$test_count $1\")\\\"\"\n+\tjunit_attrs=\"name=\\\"$(xml_attr_encode --no-lf \"$this_test.$test_count $1\")\\\"\"\n \tshift\n \tjunit_attrs=\"$junit_attrs classname=\\\"$this_test\\\"\"\n \tjunit_attrs=\"$junit_attrs time=\\\"$(test-tool \\\n@@ -122,5 +122,11 @@ write_junit_xml () {\n }\n \n xml_attr_encode () {\n-\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n+\tif test \"x$1\" = \"x--no-lf\"\n+\tthen\n+\t\tshift\n+\t\tprintf '%s' \"$*\" | test-tool xml-encode\n+\telse\n+\t\tprintf '%s\\n' \"$@\" | test-tool xml-encode\n+\tfi\n }\n-- \ngitgitgadget\n\n"},{"id":"455716","messageId":"8f5b112bd08dcaf63ea764be71a17942c184de0e.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 04/12] ci/run-build-and-tests: take a more high-level view","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:48Z","receivedAt":"2022-05-21T22:19:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nIn the web UI of GitHub workflows, failed runs are presented with the\njob step that failed auto-expanded. In the current setup, this is not\nhelpful at all because that shows only the output of `prove`, which says\nwhich test failed, but not in what way.\n\nWhat would help understand the reader what went wrong is the verbose\ntest output of the failed test.\n\nThe logs of the failed runs do contain that verbose test output, but it\nis shown in the _next_ step (which is marked as succeeding, and is\ntherefore _not_ auto-expanded). Anyone not intimately familiar with this\nwould completely miss the verbose test output, being left mostly\npuzzled with the test failures.\n\nWe are about to show the failed test cases' output in the _same_ step,\nso that the user has a much easier time to figure out what was going\nwrong.\n\nBut first, we must partially revert the change that tried to improve the\nCI runs by combining the `Makefile` targets to build into a single\n`make` invocation. That might have sounded like a good idea at the time,\nbut it does make it rather impossible for the CI script to determine\nwhether the _build_ failed, or the _tests_. If the tests were run at\nall, that is.\n\nSo let's go back to calling `make` for the build, and call `make test`\nseparately so that we can easily detect that _that_ invocation failed,\nand react appropriately.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/run-build-and-tests.sh | 13 +++++++------\n 1 file changed, 7 insertions(+), 6 deletions(-)\n\ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex 280dda7d285..2818b3046ae 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -10,7 +10,7 @@ windows*) cmd //c mklink //j t\\\\.prove \"$(cygpath -aw \"$cache_dir/.prove\")\";;\n *) ln -s \"$cache_dir/.prove\" t/.prove;;\n esac\n \n-export MAKE_TARGETS=\"all test\"\n+run_tests=t\n \n case \"$jobname\" in\n linux-gcc)\n@@ -41,14 +41,15 @@ pedantic)\n \t# Don't run the tests; we only care about whether Git can be\n \t# built.\n \texport DEVOPTS=pedantic\n-\texport MAKE_TARGETS=all\n+\trun_tests=\n \t;;\n esac\n \n-# Any new \"test\" targets should not go after this \"make\", but should\n-# adjust $MAKE_TARGETS. Otherwise compilation-only targets above will\n-# start running tests.\n-make $MAKE_TARGETS\n+make\n+if test -n \"$run_tests\"\n+then\n+\tmake test\n+fi\n check_unignored_build_artifacts\n \n save_good_tree\n-- \ngitgitgadget\n\n"},{"id":"455717","messageId":"417f702a2454316f0bdc5b66eb16751272ff2989.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 05/12] ci: make it easier to find failed tests' logs in the GitHub workflow","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:49Z","receivedAt":"2022-05-21T22:19:20Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nWhen investigating a test failure, the time that matters most is the\ntime it takes from getting aware of the failure to displaying the output\nof the failing test case.\n\nYou currently have to know a lot of implementation details when\ninvestigating test failures in the CI runs. The first step is easy: the\nfailed job is marked quite clearly, but when opening it, the failed step\nis expanded, which in our case is the one running\n`ci/run-build-and-tests.sh`. This step, most notably, only offers a\nhigh-level view of what went wrong: it prints the output of `prove`\nwhich merely tells the reader which test script failed.\n\nThe actually interesting part is in the detailed log of said failed\ntest script. But that log is shown in the CI run's step that runs\n`ci/print-test-failures.sh`. And that step is _not_ expanded in the web\nUI by default. It is even marked as \"successful\", which makes it very\neasy to miss that there is useful information hidden in there.\n\nLet's help the reader by showing the failed tests' detailed logs in the\nstep that is expanded automatically, i.e. directly after the test suite\nfailed.\n\nThis also helps the situation where the _build_ failed and the\n`print-test-failures` step was executed under the assumption that the\n_test suite_ failed, and consequently failed to find any failed tests.\n\nAn alternative way to implement this patch would be to source\n`ci/print-test-failures.sh` in the `handle_test_failures` function to\nshow these logs. However, over the course of the next few commits, we\nwant to introduce some grouping which would be harder to achieve that\nway (for example, we do want a leaner, and colored, preamble for each\nfailed test script, and it would be trickier to accommodate the lack of\nnested groupings in GitHub workflows' output).\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n .github/workflows/main.yml | 12 ------------\n ci/lib.sh                  | 23 +++++++++++++++++++++++\n ci/run-build-and-tests.sh  |  3 ++-\n ci/run-test-slice.sh       |  3 ++-\n 4 files changed, 27 insertions(+), 14 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex c35200defb9..3fa88b78b6d 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -119,10 +119,6 @@ jobs:\n     - name: test\n       shell: bash\n       run: . /etc/profile && ci/run-test-slice.sh ${{matrix.nr}} 10\n-    - name: ci/print-test-failures.sh\n-      if: failure()\n-      shell: bash\n-      run: ci/print-test-failures.sh\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v2\n@@ -204,10 +200,6 @@ jobs:\n       env:\n         NO_SVN_TESTS: 1\n       run: . /etc/profile && ci/run-test-slice.sh ${{matrix.nr}} 10\n-    - name: ci/print-test-failures.sh\n-      if: failure()\n-      shell: bash\n-      run: ci/print-test-failures.sh\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v2\n@@ -261,8 +253,6 @@ jobs:\n     - uses: actions/checkout@v2\n     - run: ci/install-dependencies.sh\n     - run: ci/run-build-and-tests.sh\n-    - run: ci/print-test-failures.sh\n-      if: failure()\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v2\n@@ -292,8 +282,6 @@ jobs:\n     - uses: actions/checkout@v1\n     - run: ci/install-docker-dependencies.sh\n     - run: ci/run-build-and-tests.sh\n-    - run: ci/print-test-failures.sh\n-      if: failure()\n     - name: Upload failed tests' directories\n       if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n       uses: actions/upload-artifact@v1\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex d718f4e386d..65f5188a550 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -78,6 +78,10 @@ check_unignored_build_artifacts () {\n \t}\n }\n \n+handle_failed_tests () {\n+\treturn 1\n+}\n+\n # GitHub Action doesn't set TERM, which is required by tput\n export TERM=${TERM:-dumb}\n \n@@ -123,6 +127,25 @@ then\n \tCI_JOB_ID=\"$GITHUB_RUN_ID\"\n \tCC=\"${CC_PACKAGE:-${CC:-gcc}}\"\n \tDONT_SKIP_TAGS=t\n+\thandle_failed_tests () {\n+\t\tmkdir -p t/failed-test-artifacts\n+\t\techo \"FAILED_TEST_ARTIFACTS=t/failed-test-artifacts\" >>$GITHUB_ENV\n+\n+\t\tfor test_exit in t/test-results/*.exit\n+\t\tdo\n+\t\t\ttest 0 != \"$(cat \"$test_exit\")\" || continue\n+\n+\t\t\ttest_name=\"${test_exit%.exit}\"\n+\t\t\ttest_name=\"${test_name##*/}\"\n+\t\t\tprintf \"\\\\e[33m\\\\e[1m=== Failed test: ${test_name} ===\\\\e[m\\\\n\"\n+\t\t\tcat \"t/test-results/$test_name.out\"\n+\n+\t\t\ttrash_dir=\"t/trash directory.$test_name\"\n+\t\t\tcp \"t/test-results/$test_name.out\" t/failed-test-artifacts/\n+\t\t\ttar czf t/failed-test-artifacts/\"$test_name\".trash.tar.gz \"$trash_dir\"\n+\t\tdone\n+\t\treturn 1\n+\t}\n \n \tcache_dir=\"$HOME/none\"\n \ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex 2818b3046ae..1ede75e5556 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -48,7 +48,8 @@ esac\n make\n if test -n \"$run_tests\"\n then\n-\tmake test\n+\tmake test ||\n+\thandle_failed_tests\n fi\n check_unignored_build_artifacts\n \ndiff --git a/ci/run-test-slice.sh b/ci/run-test-slice.sh\nindex f8c2c3106a2..63358c23e11 100755\n--- a/ci/run-test-slice.sh\n+++ b/ci/run-test-slice.sh\n@@ -12,6 +12,7 @@ esac\n \n make --quiet -C t T=\"$(cd t &&\n \t./helper/test-tool path-utils slice-tests \"$1\" \"$2\" t[0-9]*.sh |\n-\ttr '\\n' ' ')\"\n+\ttr '\\n' ' ')\" ||\n+handle_failed_tests\n \n check_unignored_build_artifacts\n-- \ngitgitgadget\n\n"},{"id":"455718","messageId":"7d2284314efc0071ad9cc9b8f2559e07310e35b0.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 06/12] ci/run-build-and-tests: add some structure to the GitHub workflow output","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:50Z","receivedAt":"2022-05-21T22:19:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nThe current output of Git's GitHub workflow can be quite confusing,\nespecially for contributors new to the project.\n\nTo make it more helpful, let's introduce some collapsible grouping.\nInitially, readers will see the high-level view of what actually\nhappened (did the build fail, or the test suite?). To drill down, the\nrespective group can be expanded.\n\nNote: sadly, workflow output currently cannot contain any nested groups\n(see https://github.com/actions/runner/issues/802 for details),\ntherefore we take pains to ensure to end any previous group before\nstarting a new one.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/lib.sh                 | 56 ++++++++++++++++++++++++++++++++++-----\n ci/run-build-and-tests.sh |  4 +--\n ci/run-test-slice.sh      |  2 +-\n 3 files changed, 52 insertions(+), 10 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 65f5188a550..f8cb79e44f0 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -1,5 +1,50 @@\n # Library of functions shared by all CI scripts\n \n+if test true != \"$GITHUB_ACTIONS\"\n+then\n+\tbegin_group () { :; }\n+\tend_group () { :; }\n+\n+\tgroup () {\n+\t\tshift\n+\t\t\"$@\"\n+\t}\n+\tset -x\n+else\n+\tbegin_group () {\n+\t\tneed_to_end_group=t\n+\t\techo \"::group::$1\" >&2\n+\t\tset -x\n+\t}\n+\n+\tend_group () {\n+\t\ttest -n \"$need_to_end_group\" || return 0\n+\t\tset +x\n+\t\tneed_to_end_group=\n+\t\techo '::endgroup::' >&2\n+\t}\n+\ttrap end_group EXIT\n+\n+\tgroup () {\n+\t\tset +x\n+\t\tbegin_group \"$1\"\n+\t\tshift\n+\t\t\"$@\"\n+\t\tres=$?\n+\t\tend_group\n+\t\treturn $res\n+\t}\n+\n+\tbegin_group \"CI setup\"\n+fi\n+\n+# Set 'exit on error' for all CI scripts to let the caller know that\n+# something went wrong.\n+#\n+# We already enabled tracing executed commands earlier. This helps by showing\n+# how # environment variables are set and and dependencies are installed.\n+set -e\n+\n skip_branch_tip_with_tag () {\n \t# Sometimes, a branch is pushed at the same time the tag that points\n \t# at the same commit as the tip of the branch is pushed, and building\n@@ -88,12 +133,6 @@ export TERM=${TERM:-dumb}\n # Clear MAKEFLAGS that may come from the outside world.\n export MAKEFLAGS=\n \n-# Set 'exit on error' for all CI scripts to let the caller know that\n-# something went wrong.\n-# Set tracing executed commands, primarily setting environment variables\n-# and installing dependencies.\n-set -ex\n-\n if test -n \"$SYSTEM_COLLECTIONURI\" || test -n \"$SYSTEM_TASKDEFINITIONSURI\"\n then\n \tCI_TYPE=azure-pipelines\n@@ -138,7 +177,7 @@ then\n \t\t\ttest_name=\"${test_exit%.exit}\"\n \t\t\ttest_name=\"${test_name##*/}\"\n \t\t\tprintf \"\\\\e[33m\\\\e[1m=== Failed test: ${test_name} ===\\\\e[m\\\\n\"\n-\t\t\tcat \"t/test-results/$test_name.out\"\n+\t\t\tgroup \"Failed test: $test_name\" cat \"t/test-results/$test_name.out\"\n \n \t\t\ttrash_dir=\"t/trash directory.$test_name\"\n \t\t\tcp \"t/test-results/$test_name.out\" t/failed-test-artifacts/\n@@ -233,3 +272,6 @@ linux-leaks)\n esac\n \n MAKEFLAGS=\"$MAKEFLAGS CC=${CC:-cc}\"\n+\n+end_group\n+set -x\ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex 1ede75e5556..7abfa00adc0 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -45,10 +45,10 @@ pedantic)\n \t;;\n esac\n \n-make\n+group Build make\n if test -n \"$run_tests\"\n then\n-\tmake test ||\n+\tgroup \"Run tests\" make test ||\n \thandle_failed_tests\n fi\n check_unignored_build_artifacts\ndiff --git a/ci/run-test-slice.sh b/ci/run-test-slice.sh\nindex 63358c23e11..a3c67956a8d 100755\n--- a/ci/run-test-slice.sh\n+++ b/ci/run-test-slice.sh\n@@ -10,7 +10,7 @@ windows*) cmd //c mklink //j t\\\\.prove \"$(cygpath -aw \"$cache_dir/.prove\")\";;\n *) ln -s \"$cache_dir/.prove\" t/.prove;;\n esac\n \n-make --quiet -C t T=\"$(cd t &&\n+group \"Run tests\" make --quiet -C t T=\"$(cd t &&\n \t./helper/test-tool path-utils slice-tests \"$1\" \"$2\" t[0-9]*.sh |\n \ttr '\\n' ' ')\" ||\n handle_failed_tests\n-- \ngitgitgadget\n\n"},{"id":"455719","messageId":"98059b94a881485f763efc54346e8b19103ee64b.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 07/12] ci: optionally mark up output in the GitHub workflow","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:51Z","receivedAt":"2022-05-21T22:19:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nA couple of commands exist to spruce up the output in GitHub workflows:\nhttps://docs.github.com/en/actions/learn-github-actions/workflow-commands-for-github-actions\n\nIn addition to the `::group::<label>`/`::endgroup::` commands (which we\nalready use to structure the output of the build step better), we also\nuse `::error::`/`::notice::` to draw the attention to test failures and\nto test cases that were expected to fail but didn't.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib-functions.sh              |  4 +--\n t/test-lib-github-workflow-markup.sh | 50 ++++++++++++++++++++++++++++\n t/test-lib.sh                        |  5 ++-\n 3 files changed, 56 insertions(+), 3 deletions(-)\n create mode 100644 t/test-lib-github-workflow-markup.sh\n\ndiff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\nindex 93c03380d44..af4831a54c6 100644\n--- a/t/test-lib-functions.sh\n+++ b/t/test-lib-functions.sh\n@@ -795,7 +795,7 @@ test_verify_prereq () {\n }\n \n test_expect_failure () {\n-\ttest_start_\n+\ttest_start_ \"$@\"\n \ttest \"$#\" = 3 && { test_prereq=$1; shift; } || test_prereq=\n \ttest \"$#\" = 2 ||\n \tBUG \"not 2 or 3 parameters to test-expect-failure\"\n@@ -815,7 +815,7 @@ test_expect_failure () {\n }\n \n test_expect_success () {\n-\ttest_start_\n+\ttest_start_ \"$@\"\n \ttest \"$#\" = 3 && { test_prereq=$1; shift; } || test_prereq=\n \ttest \"$#\" = 2 ||\n \tBUG \"not 2 or 3 parameters to test-expect-success\"\ndiff --git a/t/test-lib-github-workflow-markup.sh b/t/test-lib-github-workflow-markup.sh\nnew file mode 100644\nindex 00000000000..d8dc969df4a\n--- /dev/null\n+++ b/t/test-lib-github-workflow-markup.sh\n@@ -0,0 +1,50 @@\n+# Library of functions to mark up test scripts' output suitable for\n+# pretty-printing it in GitHub workflows.\n+#\n+# Copyright (c) 2022 Johannes Schindelin\n+#\n+# This program is free software: you can redistribute it and/or modify\n+# it under the terms of the GNU General Public License as published by\n+# the Free Software Foundation, either version 2 of the License, or\n+# (at your option) any later version.\n+#\n+# This program is distributed in the hope that it will be useful,\n+# but WITHOUT ANY WARRANTY; without even the implied warranty of\n+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n+# GNU General Public License for more details.\n+#\n+# You should have received a copy of the GNU General Public License\n+# along with this program.  If not, see http://www.gnu.org/licenses/ .\n+#\n+# The idea is for `test-lib.sh` to source this file when run in GitHub\n+# workflows; these functions will then override (empty) functions\n+# that are are called at the appropriate times during the test runs.\n+\n+start_test_output () {\n+\ttest -n \"$GIT_TEST_TEE_OUTPUT_FILE\" ||\n+\tdie \"--github-workflow-markup requires --verbose-log\"\n+\tgithub_markup_output=\"${GIT_TEST_TEE_OUTPUT_FILE%.out}.markup\"\n+\t>$github_markup_output\n+\tGIT_TEST_TEE_OFFSET=0\n+}\n+\n+# No need to override start_test_case_output\n+\n+finalize_test_case_output () {\n+\ttest_case_result=$1\n+\tshift\n+\tcase \"$test_case_result\" in\n+\tfailure)\n+\t\techo >>$github_markup_output \"::error::failed: $this_test.$test_count $1\"\n+\t\t;;\n+\tfixed)\n+\t\techo >>$github_markup_output \"::notice::fixed: $this_test.$test_count $1\"\n+\t\t;;\n+\tesac\n+\techo >>$github_markup_output \"::group::$test_case_result: $this_test.$test_count $*\"\n+\ttest-tool >>$github_markup_output path-utils skip-n-bytes \\\n+\t\t\"$GIT_TEST_TEE_OUTPUT_FILE\" $GIT_TEST_TEE_OFFSET\n+\techo >>$github_markup_output \"::endgroup::\"\n+}\n+\n+# No need to override finalize_test_output\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex bdb11e28eea..29640d107ca 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -204,6 +204,9 @@ parse_option () {\n \t--write-junit-xml)\n \t\t. \"$TEST_DIRECTORY/test-lib-junit.sh\"\n \t\t;;\n+\t--github-workflow-markup)\n+\t\t. \"$TEST_DIRECTORY/test-lib-github-workflow-markup.sh\"\n+\t\t;;\n \t--stress)\n \t\tstress=t ;;\n \t--stress=*)\n@@ -1082,7 +1085,7 @@ test_start_ () {\n \ttest_count=$(($test_count+1))\n \tmaybe_setup_verbose\n \tmaybe_setup_valgrind\n-\tstart_test_case_output\n+\tstart_test_case_output \"$@\"\n }\n \n test_finish_ () {\n-- \ngitgitgadget\n\n"},{"id":"455720","messageId":"d3db5252fb8601f59c48fcac0120e1e2bcc33e03.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 08/12] ci(github): skip the logs of the successful test cases","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:52Z","receivedAt":"2022-05-21T22:19:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nIn most instances, looking at the log of failed test cases is enough to\nidentify the problem.\n\nIn some (rare?) instances, a previous test case that was marked as\nsuccessful actually has information pertaining to a later test case that\nfails.\n\nTo allow the page to load relatively quickly, let's only show the logs\nof the failed test cases to be shown. The full logs are available for\ndownload as artifacts, should a deeper investigation become necessary.\n\nCo-authored-by: Victoria Dye <vdye@github.com>\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib-github-workflow-markup.sh | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/t/test-lib-github-workflow-markup.sh b/t/test-lib-github-workflow-markup.sh\nindex d8dc969df4a..1ef0fd5ba87 100644\n--- a/t/test-lib-github-workflow-markup.sh\n+++ b/t/test-lib-github-workflow-markup.sh\n@@ -40,6 +40,10 @@ finalize_test_case_output () {\n \tfixed)\n \t\techo >>$github_markup_output \"::notice::fixed: $this_test.$test_count $1\"\n \t\t;;\n+\tok)\n+\t\t# Exit without printing the \"ok\" tests\n+\t\treturn\n+\t\t;;\n \tesac\n \techo >>$github_markup_output \"::group::$test_case_result: $this_test.$test_count $*\"\n \ttest-tool >>$github_markup_output path-utils skip-n-bytes \\\n-- \ngitgitgadget\n\n"},{"id":"455721","messageId":"7f921ffef1205775125699d0dff4ad8c39c3ea3d.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 10/12] ci: use `--github-workflow-markup` in the GitHub workflow","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:54Z","receivedAt":"2022-05-21T22:19:37Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nThis makes the output easier to digest.\n\nNote: since workflow output currently cannot contain any nested groups\n(see https://github.com/actions/runner/issues/802 for details), we need\nto remove the explicit grouping that would span the entirety of each\nfailed test script.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/lib.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex f8cb79e44f0..de6532ee8cd 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -177,7 +177,7 @@ then\n \t\t\ttest_name=\"${test_exit%.exit}\"\n \t\t\ttest_name=\"${test_name##*/}\"\n \t\t\tprintf \"\\\\e[33m\\\\e[1m=== Failed test: ${test_name} ===\\\\e[m\\\\n\"\n-\t\t\tgroup \"Failed test: $test_name\" cat \"t/test-results/$test_name.out\"\n+\t\t\tcat \"t/test-results/$test_name.markup\"\n \n \t\t\ttrash_dir=\"t/trash directory.$test_name\"\n \t\t\tcp \"t/test-results/$test_name.out\" t/failed-test-artifacts/\n@@ -189,7 +189,7 @@ then\n \tcache_dir=\"$HOME/none\"\n \n \texport GIT_PROVE_OPTS=\"--timer --jobs 10\"\n-\texport GIT_TEST_OPTS=\"--verbose-log -x\"\n+\texport GIT_TEST_OPTS=\"--verbose-log -x --github-workflow-markup\"\n \tMAKEFLAGS=\"$MAKEFLAGS --jobs=10\"\n \ttest windows != \"$CI_OS_NAME\" ||\n \tGIT_TEST_OPTS=\"--no-chain-lint --no-bin-wrappers $GIT_TEST_OPTS\"\n-- \ngitgitgadget\n\n"},{"id":"455722","messageId":"51573ef6c540abe19544e978a0110a5b51d7227d.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 09/12] ci(github): avoid printing test case preamble twice","fromName":"Victoria Dye via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:53Z","receivedAt":"2022-05-21T22:19:42Z","isPatch":true,"sender":{"key":"vdye@github.com","avatar":"https://avatars.githubusercontent.com/u/3619353?v=4"},"body":"From: Victoria Dye <vdye@github.com>\n\nWe want to mark up the test case preamble when presenting test output in\nGit's GitHub workflow. Let's suppress the non-marked-up version in that\ncase. Any information it would contain is included in the marked-up\nvariant already.\n\nSigned-off-by: Victoria Dye <vdye@github.com>\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib-functions.sh              | 2 ++\n t/test-lib-github-workflow-markup.sh | 2 ++\n 2 files changed, 4 insertions(+)\n\ndiff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\nindex af4831a54c6..89a5e146b7a 100644\n--- a/t/test-lib-functions.sh\n+++ b/t/test-lib-functions.sh\n@@ -803,6 +803,7 @@ test_expect_failure () {\n \texport test_prereq\n \tif ! test_skip \"$@\"\n \tthen\n+\t\ttest -n \"$test_skip_test_preamble\" ||\n \t\tsay >&3 \"checking known breakage of $TEST_NUMBER.$test_count '$1': $2\"\n \t\tif test_run_ \"$2\" expecting_failure\n \t\tthen\n@@ -823,6 +824,7 @@ test_expect_success () {\n \texport test_prereq\n \tif ! test_skip \"$@\"\n \tthen\n+\t\ttest -n \"$test_skip_test_preamble\" ||\n \t\tsay >&3 \"expecting success of $TEST_NUMBER.$test_count '$1': $2\"\n \t\tif test_run_ \"$2\"\n \t\tthen\ndiff --git a/t/test-lib-github-workflow-markup.sh b/t/test-lib-github-workflow-markup.sh\nindex 1ef0fd5ba87..9c5339c577a 100644\n--- a/t/test-lib-github-workflow-markup.sh\n+++ b/t/test-lib-github-workflow-markup.sh\n@@ -20,6 +20,8 @@\n # workflows; these functions will then override (empty) functions\n # that are are called at the appropriate times during the test runs.\n \n+test_skip_test_preamble=t\n+\n start_test_output () {\n \ttest -n \"$GIT_TEST_TEE_OUTPUT_FILE\" ||\n \tdie \"--github-workflow-markup requires --verbose-log\"\n-- \ngitgitgadget\n\n"},{"id":"455723","messageId":"fe355a6f03b739013957b261751b8bc3950ab533.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 12/12] ci: call `finalize_test_case_output` a little later","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:56Z","receivedAt":"2022-05-21T22:19:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nWe used to call that function already before printing the final verdict.\nHowever, now that we added grouping to the GitHub workflow output, we\nwill want to include even that part in the collapsible group for that\ntest case.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n t/test-lib.sh | 11 ++++++-----\n 1 file changed, 6 insertions(+), 5 deletions(-)\n\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 29640d107ca..9e410a5bb70 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -783,13 +783,13 @@ trap '{ code=$?; set +x; } 2>/dev/null; exit $code' INT TERM HUP\n # the test_expect_* functions instead.\n \n test_ok_ () {\n-\tfinalize_test_case_output ok \"$@\"\n \ttest_success=$(($test_success + 1))\n \tsay_color \"\" \"ok $test_count - $@\"\n+\tfinalize_test_case_output ok \"$@\"\n }\n \n test_failure_ () {\n-\tfinalize_test_case_output failure \"$@\"\n+\tfailure_label=$1\n \ttest_failure=$(($test_failure + 1))\n \tsay_color error \"not ok $test_count - $1\"\n \tshift\n@@ -799,18 +799,19 @@ test_failure_ () {\n \t\tsay_color error \"1..$test_count\"\n \t\t_error_exit\n \tfi\n+\tfinalize_test_case_output failure \"$failure_label\" \"$@\"\n }\n \n test_known_broken_ok_ () {\n-\tfinalize_test_case_output fixed \"$@\"\n \ttest_fixed=$(($test_fixed+1))\n \tsay_color error \"ok $test_count - $@ # TODO known breakage vanished\"\n+\tfinalize_test_case_output fixed \"$@\"\n }\n \n test_known_broken_failure_ () {\n-\tfinalize_test_case_output broken \"$@\"\n \ttest_broken=$(($test_broken+1))\n \tsay_color warn \"not ok $test_count - $@ # TODO known breakage\"\n+\tfinalize_test_case_output broken \"$@\"\n }\n \n test_debug () {\n@@ -1136,10 +1137,10 @@ test_skip () {\n \n \tcase \"$to_skip\" in\n \tt)\n-\t\tfinalize_test_case_output skip \"$@\"\n \n \t\tsay_color skip \"ok $test_count # skip $1 ($skipped_reason)\"\n \t\t: true\n+\t\tfinalize_test_case_output skip \"$@\"\n \t\t;;\n \t*)\n \t\tfalse\n-- \ngitgitgadget\n"},{"id":"455724","messageId":"370b08d3a1154ba3d17b91c0afc5ff015fa4b73c.1653171536.git.gitgitgadget@gmail.com","threadId":"57297","inReplyTo":"pull.1117.v3.git.1653171536.gitgitgadget@gmail.com","subject":"[PATCH v3 11/12] ci(github): mention where the full logs can be found","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-21T22:18:55Z","receivedAt":"2022-05-21T22:19:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nThe full logs are contained in the `failed-tests-*.zip` artifacts that\nare attached to the failed CI run. Since this is not immediately\nobvious to the well-disposed reader, let's mention it explicitly.\n\nSuggested-by: Victoria Dye <vdye@github.com>\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n ci/lib.sh | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex de6532ee8cd..2f6d9d26e40 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -177,6 +177,7 @@ then\n \t\t\ttest_name=\"${test_exit%.exit}\"\n \t\t\ttest_name=\"${test_name##*/}\"\n \t\t\tprintf \"\\\\e[33m\\\\e[1m=== Failed test: ${test_name} ===\\\\e[m\\\\n\"\n+\t\t\techo \"The full logs are in the artifacts attached to this run.\"\n \t\t\tcat \"t/test-results/$test_name.markup\"\n \n \t\t\ttrash_dir=\"t/trash directory.$test_name\"\n-- \ngitgitgadget\n\n"},{"id":"455725","messageId":"xmqq35h2cwrm.fsf@gitster.g","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2205212307090.352@tvgsbejvaqbjf.bet","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-21T23:05:01Z","receivedAt":"2022-05-21T23:13:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> * print the verbose logs only for the failed test cases (to massively cut\n>>   down on the size of the log, particularly when there's only a couple\n>>   failures in a test file with a lot of passing tests).\n>\n> That's an amazingly simple trick to improve the speed by a ton, indeed.\n> Thank you for this splendid idea!\n>\n>> * skip printing the full text of the test in 'finalize_test_case_output'\n>>   when creating the group, i.e., use '$1' instead of '$*' (in both passing\n>>   and failing tests, this information is already printed via some other\n>>   means).\n>>\n>> If you wanted to make sure a user could still access the full failure logs\n>> (i.e., including the \"ok\" test results), you could print a link to the\n>> artifacts page as well - that way, all of the information we currently\n>> provide to users can still be found somewhere.\n>\n> That's a good point, I added that hint to the output (the link is\n> unfortunately not available at the time we print that advice).\n\nhttps://github.com/git/git/runs/6539786128 shows that all in-flight\ntopics merged to 'seen', except for the ds/bundle-uri-more, passes\nthe linux-leaks job.  The ds/bundle-uri-more topic introduces some\nleaks to commands that happen to be used in tests that are marked as\nleak-checker clean, making the job fail.\n\nWhich makes a great guinea pig for the CI output improvement topic.\n\nSo, I created two variants of 'seen' with this linux-leaks breakage.\nOne is with the js/ci-github-workflow-markup topic on this thread.\nThe other one is with the ab/ci-github-workflow-markup topic (which\nuses a preliminary clean-up ab/ci-setup-simplify topic as its base).\nThey should show the identical test results and failures.\n\nAnd here are their output:\n\n - https://github.com/git/git/runs/6539835065\n - https://github.com/git/git/runs/6539900608\n\nIf I recall correctly, the selling point of the ab/* variant over\njs/* variant was that it would give quicker UI response compared to\nthe former, but other than that, both variants' UI are supposed to\nbe as newbie friendly as the other.\n\nWhen I tried the former, it reacted too poorly to my attempt to\nscroll (with mouse scroll wheel, if it makes a difference) that\nsometimes I was staring a blank dark-gray space for a few seconds\nwaiting for it to be filled by something, which was a bit jarring\nexperience.  When I tried the latter, it didn't show anything to\nhelp diagnosing the details of the breakage in \"run make test\" step\nand the user needed to know \"print test failures\" needs to be looked\nat, which I am not sure is an inherent limitation of the approach.\nAfter the single extra click, navigating the test output to find the\nfailed steps among many others that succeeded was not a very pleasant\nexperience.\n\nThose who are interested in UX experiment may want to visit these\ntwo output to see how usable each of these is for themselves.\n\nThanks.\n\n\n\n"},{"id":"455731","messageId":"nycvar.QRO.7.76.6.2205222045130.352@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"xmqq35h2cwrm.fsf@gitster.g","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-05-22T18:48:30Z","receivedAt":"2022-05-22T18:48:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sat, 21 May 2022, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n> >> * print the verbose logs only for the failed test cases (to massively cut\n> >>   down on the size of the log, particularly when there's only a couple\n> >>   failures in a test file with a lot of passing tests).\n> >\n> > That's an amazingly simple trick to improve the speed by a ton, indeed.\n> > Thank you for this splendid idea!\n> >\n> >> * skip printing the full text of the test in 'finalize_test_case_output'\n> >>   when creating the group, i.e., use '$1' instead of '$*' (in both passing\n> >>   and failing tests, this information is already printed via some other\n> >>   means).\n> >>\n> >> If you wanted to make sure a user could still access the full failure logs\n> >> (i.e., including the \"ok\" test results), you could print a link to the\n> >> artifacts page as well - that way, all of the information we currently\n> >> provide to users can still be found somewhere.\n> >\n> > That's a good point, I added that hint to the output (the link is\n> > unfortunately not available at the time we print that advice).\n>\n> https://github.com/git/git/runs/6539786128 shows that all in-flight\n> topics merged to 'seen', except for the ds/bundle-uri-more, passes\n> the linux-leaks job.  The ds/bundle-uri-more topic introduces some\n> leaks to commands that happen to be used in tests that are marked as\n> leak-checker clean, making the job fail.\n>\n> Which makes a great guinea pig for the CI output improvement topic.\n>\n> So, I created two variants of 'seen' with this linux-leaks breakage.\n> One is with the js/ci-github-workflow-markup topic on this thread.\n> The other one is with the ab/ci-github-workflow-markup topic (which\n> uses a preliminary clean-up ab/ci-setup-simplify topic as its base).\n> They should show the identical test results and failures.\n>\n> And here are their output:\n>\n>  - https://github.com/git/git/runs/6539835065\n\nI see that this is still with the previous iteration, and therefore\nexposes the same speed (or slowness) as was investigated so wonderfully by\nVictoria.\n\nSo I really do not understand why you pointed to that run, given that it\nstill contains all the successful test cases' logs, which contributes in a\nmajor way to said slowness.\n\nMaybe you meant to refer to https://github.com/git/git/runs/6540394142\ninstead, which at least for me loads much faster _and_ makes the output as\nhelpful as my intention was?\n\nCiao,\nDscho\n\n>  - https://github.com/git/git/runs/6539900608\n>\n> If I recall correctly, the selling point of the ab/* variant over\n> js/* variant was that it would give quicker UI response compared to\n> the former, but other than that, both variants' UI are supposed to\n> be as newbie friendly as the other.\n>\n> When I tried the former, it reacted too poorly to my attempt to\n> scroll (with mouse scroll wheel, if it makes a difference) that\n> sometimes I was staring a blank dark-gray space for a few seconds\n> waiting for it to be filled by something, which was a bit jarring\n> experience.  When I tried the latter, it didn't show anything to\n> help diagnosing the details of the breakage in \"run make test\" step\n> and the user needed to know \"print test failures\" needs to be looked\n> at, which I am not sure is an inherent limitation of the approach.\n> After the single extra click, navigating the test output to find the\n> failed steps among many others that succeeded was not a very pleasant\n> experience.\n>\n> Those who are interested in UX experiment may want to visit these\n> two output to see how usable each of these is for themselves.\n>\n> Thanks.\n>\n>\n>\n>\n>\n"},{"id":"455732","messageId":"xmqqfsl1bcy6.fsf@gitster.g","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2205222045130.352@tvgsbejvaqbjf.bet","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-22T19:10:41Z","receivedAt":"2022-05-22T19:10:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> I see that this is still with the previous iteration, and therefore\n> exposes the same speed (or slowness) as was investigated so wonderfully by\n> Victoria.\n>\n> So I really do not understand why you pointed to that run, given that it\n\nSimply because your updated version came to my tree a lot after I\nprepared two trees that are otherwise identical for comparison to\nwrite the message you are responding to.  If the new round is much\nimproved than the previous one, that is a very good news.\n\nI do not appreciate that you have to always talk back to others in\nsuch an aggressive tone, and I do not think it is only to me, by the\nway.\n\nYou could have said the same thing in a lot more cordial way,\ne.g. \"There is a newer version than those being compared---could you\nlook at this run instead for comparison, even though admittably\nthere probably are changes in other topics in flight so the exact\nfailures may be different?\"\n\n"},{"id":"455734","messageId":"xmqqee0l9mhl.fsf@gitster.g","threadId":"57297","inReplyTo":"xmqq35h2cwrm.fsf@gitster.g","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-22T23:27:34Z","receivedAt":"2022-05-22T23:27:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Which makes a great guinea pig for the CI output improvement topic.\n>\n> So, I created two variants of 'seen' with this linux-leaks breakage.\n> One is with the js/ci-github-workflow-markup topic on this thread.\n> The other one is with the ab/ci-github-workflow-markup topic (which\n> uses a preliminary clean-up ab/ci-setup-simplify topic as its base).\n> They should show the identical test results and failures.\n\nThe two runs to look at have been updated.\n\n - The one with Ævar's change was missing the primary \"workflow\n   markup\" topic (it only had preliminary clean-up topic), so it is\n   not a fair feature-to-feature comparison to begin with.\n\n - The other one with Johannes's change was done with the version\n   before the latest round from yesterday, which has improvements.\n\nWith all the other in-flight topics (including the one that shows\nfailures in linux-leaks job) merged to the same base in the same\norder, I prepared two variants of 'seen' that resulted in these\nlogs:\n\n - https://github.com/git/git/runs/6546816978\n - https://github.com/git/git/runs/6546750379\n\nOne is with both of the required topics from Ævar (with a fix-up [*]),\nand the other is with the latest from Johannes's series.\n\nI do not want to taint other folks' eyes with my observations, so I'd\nsend my impression in a separate message as a response to this\nmessage after waiting for some time.\n\nThanks.\n\n[Footnote]\n\n* 76253615 (ci: optionally mark up output in the GitHub workflow,\n  2022-04-21) added references to ci/print-test-failures.sh and\n  ci/print-test-failures-github.sh to the workflow file, while the\n  latter script does not exist, but it appears that these references\n  want to run the same script, so I've made a stupid and obvious\n  fix-up today before pushing the result of merging all out.\n\n  This prevented \"make test || ci/print-test-failures.sh\" from\n  running correctly [*], ever since 76253615 (ci: optionally mark up\n  output in the GitHub workflow, 2022-04-21) was queued, and it\n  seems that nobody noticed nor complained.  Sigh.\n"},{"id":"455759","messageId":"220523.86ee0kzjix.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"xmqq35h2cwrm.fsf@gitster.g","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-05-23T09:05:37Z","receivedAt":"2022-05-23T09:27:45Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, May 21 2022, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n>>> * print the verbose logs only for the failed test cases (to massively cut\n>>>   down on the size of the log, particularly when there's only a couple\n>>>   failures in a test file with a lot of passing tests).\n>>\n>> That's an amazingly simple trick to improve the speed by a ton, indeed.\n>> Thank you for this splendid idea!\n>>\n>>> * skip printing the full text of the test in 'finalize_test_case_output'\n>>>   when creating the group, i.e., use '$1' instead of '$*' (in both passing\n>>>   and failing tests, this information is already printed via some other\n>>>   means).\n>>>\n>>> If you wanted to make sure a user could still access the full failure logs\n>>> (i.e., including the \"ok\" test results), you could print a link to the\n>>> artifacts page as well - that way, all of the information we currently\n>>> provide to users can still be found somewhere.\n>>\n>> That's a good point, I added that hint to the output (the link is\n>> unfortunately not available at the time we print that advice).\n>\n> https://github.com/git/git/runs/6539786128 shows that all in-flight\n> topics merged to 'seen', except for the ds/bundle-uri-more, passes\n> the linux-leaks job.  The ds/bundle-uri-more topic introduces some\n> leaks to commands that happen to be used in tests that are marked as\n> leak-checker clean, making the job fail.\n>\n> Which makes a great guinea pig for the CI output improvement topic.\n>\n> So, I created two variants of 'seen' with this linux-leaks breakage.\n> One is with the js/ci-github-workflow-markup topic on this thread.\n> The other one is with the ab/ci-github-workflow-markup topic (which\n> uses a preliminary clean-up ab/ci-setup-simplify topic as its base).\n> They should show the identical test results and failures.\n>\n> And here are their output:\n>\n>  - https://github.com/git/git/runs/6539835065\n>  - https://github.com/git/git/runs/6539900608\n>\n> If I recall correctly, the selling point of the ab/* variant over\n> js/* variant was that it would give quicker UI response compared to\n> the former, but other than that, both variants' UI are supposed to\n> be as newbie friendly as the other.\n\n...\n\n> When I tried the former, it reacted too poorly to my attempt to\n> scroll (with mouse scroll wheel, if it makes a difference) that\n> sometimes I was staring a blank dark-gray space for a few seconds\n> waiting for it to be filled by something, which was a bit jarring\n> experience.  When I tried the latter, it didn't show anything to\n> help diagnosing the details of the breakage in \"run make test\" step\n> and the user needed to know \"print test failures\" needs to be looked\n> at, which I am not sure is an inherent limitation of the approach.\n> After the single extra click, navigating the test output to find the\n> failed steps among many others that succeeded was not a very pleasant\n> experience.\n>\n> Those who are interested in UX experiment may want to visit these\n> two output to see how usable each of these is for themselves.\n\nRe selling point & feature comparison: The point of the ab/* variant was\nto re-roll Johannes's onto a \"base\" topic that made much of his\nunnecessary, because the building up of features to emit GitHub markup\ncan be replaced by unrolling things like \"make\" and \"make test\" to the\ntop-level.\n\nThat has its own UX benefits, e.g. you can see at a glance what command\nwas run and what the environment was, and \"make\" and \"make test\" are now\nsplit up from one monolithic \"build and test\" step.\n\nBut the primary intention was not to provide a prettier UX, but to show\nthat this arrangement made sense. I was hoping that Johannes would reply\nwith some variant of \"ah, I see what you mean, that does make things\nsimpler!\" and run with it, but alas...\n\nSo small bits in the UX like what you pointed out with needing an extra\nclick are in there, that one would be easy to solve, it's because we\n\"focus\" on the last step with a false exit code, so we'd just have to\narrange for the \"print\" step to be that step.\n\nAnyway, the v3 CL of Johannes's series claims that the re-roll \"improves\nthe time to load pages\".\n\nI ran both the Firefox and Chrome debugger with performance benchmarks\nagainst:\n\n    https://github.com/git/git/runs/6540394142\n\nAnd:\n\n    https://github.com/avar/git/runs/6551581584?check_suite_focus=true\n\nThe former is what Johannes noted as the correct v3 in\nhttps://lore.kernel.org/git/nycvar.QRO.7.76.6.2205222045130.352@tvgsbejvaqbjf.bet/,\nthe latter is the current \"seen\" with ab/ci-github-workflow-markup\nreverted, i.e. just my \"base\" changes.\n\nIn Chrome/Firefox the time to load the page (as in the spinner stops,\nand we \"focus\" on the right content) is:\n\n    JS: ~60s / ~80s \n    Æ: ~25s / ~18s\n\nThis is with Chrome Version 101.0.4951.54 (Official Build) (64-bit) and\nFirefox 91.8.0esr (64-bit), both on a Debain Linux x86_64 Dell laptop.\n\nThe case of Chrome is quite revealing (since its developer tools seem to\nshow a better summary). It shows that the \"Æ\" version spent ~200ms on\n\"scripting\", ~1ms on \"rendering\", and ~20k ms \"idle\".\n\nFor \"JS\" that's ~30k ms on \"scripting\", 15k ms on \"rendering\", then 7k\nms on \"painting\" (which is ~0ms in the other one). 7k ms are spent on\n\"idle\".\n\nSo these are basically the same performance results as I reported in\nearlier iterations.\n\nI think a v4 of this series really deserves a much less terse\nCL. I.e. there are specific reports about major slowdowns in the UX. Any\nre-roll should really be re-testing those with the same/similar software\nand reporting before/after results.\n\nClearly the primary goal of improving the CI UX should not be to\noptimize the rendering of the results as a goal in itself, but in this\ncase it becomes *so slow* that it precludes certain major use-cases,\nsuch as seeing a failure and being able to view it in some timely\nfashion.\n\n"},{"id":"455765","messageId":"nycvar.QRO.7.76.6.2205231455200.352@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"xmqqfsl1bcy6.fsf@gitster.g","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-05-23T12:58:37Z","receivedAt":"2022-05-23T12:59:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sun, 22 May 2022, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n> > I see that this is still with the previous iteration, and therefore\n> > exposes the same speed (or slowness) as was investigated so wonderfully by\n> > Victoria.\n> >\n> > So I really do not understand why you pointed to that run, given that it\n>\n> Simply because your updated version came to my tree a lot after I\n> prepared two trees that are otherwise identical for comparison to\n> write the message you are responding to.\n\nOh sorry, I only noticed that your mail came in after I sent the new\niteration, and I incorrectly thought that you had put the patch series\ninto the Stalled/To-Drop pile, so I assumed that your mail was in response\nto my new iteration.\n\nI had missed that you replied to v2 instead of to v3.\n\n> I do not appreciate that you have to always talk back to others in\n> such an aggressive tone\n\nI apologize for that. As you might have guessed, it was not my intention\nto be aggressive in any way. I merely meant to express my puzzlement, and\nyour explanation resolved that very nicely.\n\nThank you,\nDscho\n"},{"id":"455805","messageId":"nycvar.QRO.7.76.6.2205232040130.352@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"220523.86ee0kzjix.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-05-23T18:41:22Z","receivedAt":"2022-05-23T19:00:37Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ævar,\n\nOn Mon, 23 May 2022, Ævar Arnfjörð Bjarmason wrote:\n\n> Re selling point & feature comparison: The point of the ab/* variant was\n> to re-roll Johannes's onto a \"base\" topic that made much of his\n> unnecessary, because the building up of features to emit GitHub markup\n> can be replaced by unrolling things like \"make\" and \"make test\" to the\n> top-level.\n>\n> That has its own UX benefits, e.g. you can see at a glance what command\n> was run and what the environment was, and \"make\" and \"make test\" are now\n> split up from one monolithic \"build and test\" step.\n>\n> But the primary intention was not to provide a prettier UX, but to show\n> that this arrangement made sense. I was hoping that Johannes would reply\n> with some variant of \"ah, I see what you mean, that does make things\n> simpler!\" and run with it, but alas...\n\nI believe that we share the goal to make the Git project more welcoming\nand easier to navigate for new contributors.\n\nThe patch series you wanted me to look at claims to make the CI/PR\ndefinitions/scripts simpler. As it matters more to contributors how to\ninvestigate test failures, i.e. what information they are provided about\nthe failures, I disagree that that patch series needs to be connected to\nmy patch series in any way.\n\nFurther, the result does not look like a simplification to me. For\nexample, I consider it an absolute no-go to remove the remnants of Azure\nPipelines support. As I had hinted, and as you saw on the git-security\nlist, I require this support for embargoed releases. That’s what I did\nwhen working on the patches that made it into v2.35.2. In my book,\nremoving such vital (if dormant) code is not a simplification, but a\nChesterton’s Fence. While we do not need to use Azure Pipelines for our\nregular CI, we definitely need it for embargoed releases. “Simply revert\nit back” is not an excuse for removing something that should not be\nremoved in the first place.\n\nAs another example where I have a different concept of what constitutes\n“simple”: In Git for Windows’ fork, we carry a patch that integrates the\n`git-subtree` tests into the CI builds. This patch touches two places,\n`ci/run-build-and-tests.sh` and `ci/run-test-slice.sh`. These changes\nwould be inherited by any CI definition that uses the scripts in `ci/`.\nWith the proposed patches, there are four places to patch, and they are\nall limited to the GitHub workflow definition. Since you asked me for my\nassessment: this is de-DRYing the code, making it more cumbersome instead\nof simpler.\n\nIn other words, I have fundamental objections about the approach and about\ntying it to the patches that improve the output of Git’s CI/PR runs.\n\n> In Chrome/Firefox the time to load the page (as in the spinner stops,\n> and we \"focus\" on the right content) is:\n>\n>     JS: ~60s / ~80s\n>     Æ: ~25s / ~18s\n\nMy focus is on the experience of occasional and new contributors who need\nto investigate test failures in the CI/PR runs. In this thread, we already\ndiscussed the balance between speed of loading the page on the one hand\nand how well the reader is guided toward the relevant parts on the other\nhand. I disagree with you that the former should be prioritized over the\nlatter, on the contrary, guiding the readers along a path to success is\nmuch more important than optimizing for a quick page load.\n\nMost contributors who chimed in seemed to not mind a longer page load time\nanyway, as long as the result would help them identify quickly what causes\nthe test failures. Besides, the page load times are only likely to become\nbetter anyway, as GitHub engineers continuously improve Actions.\n\nCiao,\nDscho\n"},{"id":"455807","messageId":"xmqqwnecqdti.fsf@gitster.g","threadId":"57297","inReplyTo":"xmqqee0l9mhl.fsf@gitster.g","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-23T18:55:05Z","receivedAt":"2022-05-23T19:20:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I do not want to taint other folks' eyes with my observations, so I'd\n> send my impression in a separate message as a response to this\n> message after waiting for some time.\n\nBetween the previous and latest of the Johannes's topic, the test\noutput got a lot shorter by discarding the \"ok\" output and keeping\nonly the failures and skips.  Because the readers are mostly\ninterested in seeing failures (they can download the full log if\nthey want to), and this design decision probably makes sense to me.\nThe same \"while scrolling, the user has to stare into the gray void\nfor several seconds\" is still there and needs a bit of getting used\nto (I do not know if it is a browser's problem, or something the\noutput can help giving a better user experience---the lines in the\nfolded part may probably not be \"counted\" correctly or something\nsilly like that).\n\nThe ones with the topic from Ævar last night, as I've mentioned\nalready, lacked the main part of the logic, and it wouldn't have\nworked correctly because there was a show-stopper bug in one of the\nsteps in it.  With that fixed, the \"extra click\" I complained last\nnight seems to be gone.  I guess the same \"discard the test steps\nthat successfully ran\" trick would give us the same \"shorter\"\noutput.  I observe the same \"staring into the gray void while\nscrolling\" when it comes to the print-test-failures output, just as\nin the output from Johannes's topic.\n\nCommon to the both approaches, folding output from each test piece\nto one line (typically \"ok\" but sometimes \"failed\" heading) may be\nthe source of UI responsiveness irritation I have been observing,\nbut I wonder, with the removal of all \"ok\" pieces, it may make sense\nnot to fold anything and instead give a flat \"here are the traces of\nall failed and skipped tests\".\n\nIn any case, either implementation seems to give us a good\nimprovement over what is in 'master'.\n\nThanks.\n"},{"id":"455812","messageId":"nycvar.QRO.7.76.6.2205232108440.352@tvgsbejvaqbjf.bet","threadId":"57297","inReplyTo":"xmqqwnecqdti.fsf@gitster.g","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-05-23T19:21:36Z","receivedAt":"2022-05-23T19:44:20Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Mon, 23 May 2022, Junio C Hamano wrote:\n\n> [...] the test output got a lot shorter by discarding the \"ok\" output\n> and keeping only the failures and skips.  Because the readers are mostly\n> interested in seeing failures (they can download the full log if\n> they want to), and this design decision probably makes sense to me.\n\nFor the record, Victoria suggested to group by file rather than by failed\ntest case.\n\nHowever, I do speak from a lot of experience diagnosing test failures in\nCI/PR runs when I say: it is frequently very helpful to have a look at one\nfailed test case at a time. I'd much rather suffer a minor lag while\nscrolling than having to find the boundaries manually, in particular when\n`test_expect_failure` test cases are present (which are reported as\n\"broken\" in the current iteration instead of \"failed\").\n\nBesides, the scroll issue is probably similar between both approaches to\ngrouping (and may be independent of the grouping, as you pointed out by\nreporting similar issues in the current `print-test-failures` step), and\nis something I hope the Actions engineers are working on.\n\n> Common to the both approaches, folding output from each test piece\n> to one line (typically \"ok\" but sometimes \"failed\" heading) may be\n> the source of UI responsiveness irritation I have been observing,\n> but I wonder, with the removal of all \"ok\" pieces, it may make sense\n> not to fold anything and instead give a flat \"here are the traces of\n> all failed and skipped tests\".\n\nAs I mentioned above, I'd rather keep the grouping by failed test case.\n\nObviously, the ideal way to decide would be to set up some A/B testing\nwith real people, but I have no way to set up anything like that.\n\n> In any case, either implementation seems to give us a good improvement\n> over what is in 'master'.\n\nThere are two things I would like to add:\n\n- In the current iteration's summary page, you will see the failed test\n  cases' titles in the errors, and they are clickable (and will get you to\n  the corresponding part of the logs). I find this very convenient.\n\n- The addition of the suggestion to look at the run's artifacts for the\n  full logs might not look like a big deal, but I bet that it will help in\n  particular new contributors. This was yet another great suggestion by\n  Victoria.\n\nThanks,\nDscho\n\n"},{"id":"455879","messageId":"220524.86y1yrwaw0.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"nycvar.QRO.7.76.6.2205232040130.352@tvgsbejvaqbjf.bet","subject":"Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-05-24T08:40:43Z","receivedAt":"2022-05-24T09:14:13Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, May 23 2022, Johannes Schindelin wrote:\n\n> Hi Ævar,\n>\n> On Mon, 23 May 2022, Ævar Arnfjörð Bjarmason wrote:\n>\n>> Re selling point & feature comparison: The point of the ab/* variant was\n>> to re-roll Johannes's onto a \"base\" topic that made much of his\n>> unnecessary, because the building up of features to emit GitHub markup\n>> can be replaced by unrolling things like \"make\" and \"make test\" to the\n>> top-level.\n>>\n>> That has its own UX benefits, e.g. you can see at a glance what command\n>> was run and what the environment was, and \"make\" and \"make test\" are now\n>> split up from one monolithic \"build and test\" step.\n>>\n>> But the primary intention was not to provide a prettier UX, but to show\n>> that this arrangement made sense. I was hoping that Johannes would reply\n>> with some variant of \"ah, I see what you mean, that does make things\n>> simpler!\" and run with it, but alas...\n>\n> I believe that we share the goal to make the Git project more welcoming\n> and easier to navigate for new contributors.\n\nYes, definitely.\n\n> The patch series you wanted me to look at claims to make the CI/PR\n> definitions/scripts simpler. As it matters more to contributors how to\n> investigate test failures, i.e. what information they are provided about\n> the failures, I disagree that that patch series needs to be connected to\n> my patch series in any way.\n\nOur two set of patches change different parts of the CI UX, so no. The\nset of patches I've been proposing isn't just making CI/PR\ndefinitions/scripts simpler, although it also does that.\n\nSo e.g. in your patches you need to massage the CI output to split the\n\"build\" step from the \"test\" step. As you can see in an earlier RFC\nre-roll of them on top of my topic that something you'd get for free:\nhttps://lore.kernel.org/git/RFC-cover-v5-00.10-00000000000-20220421T183001Z-avarab@gmail.com/\n\n> Further, the result does not look like a simplification to me. For\n> example, I consider it an absolute no-go to remove the remnants of Azure\n> Pipelines support. As I had hinted, and as you saw on the git-security\n> list, I require this support for embargoed releases. That’s what I did\n> when working on the patches that made it into v2.35.2. In my book,\n> removing such vital (if dormant) code is not a simplification, but a\n> Chesterton’s Fence. While we do not need to use Azure Pipelines for our\n> regular CI, we definitely need it for embargoed releases. “Simply revert\n> it back” is not an excuse for removing something that should not be\n> removed in the first place.\n\nCan you please reply to this 3 month old and still-waiting-on-your-reply\nE-Mail on this topic so we can figure out a way forward with this:\nhttps://lore.kernel.org/git/220222.86y2236ndp.gmgdl@evledraar.gmail.com/\n\n> As another example where I have a different concept of what constitutes\n> “simple”: In Git for Windows’ fork, we carry a patch that integrates the\n> `git-subtree` tests into the CI builds. This patch touches two places,\n> `ci/run-build-and-tests.sh` and `ci/run-test-slice.sh`. These changes\n> would be inherited by any CI definition that uses the scripts in `ci/`.\n> With the proposed patches, there are four places to patch, and they are\n> all limited to the GitHub workflow definition. Since you asked me for my\n> assessment: this is de-DRYing the code, making it more cumbersome instead\n> of simpler.\n\nNo, you'd still have two places to patch:\n\n 1. The top-level Makefile to have \"make test\" run those subtree tests\n    depending on some flag, i.e. the same as your\n    ci/run-build-and-tests.sh.\n\n 2. ci/run-test-slice.sh as before (which is only needed for the\n Windows-specific tests).\n\nBecause we'd be having the Makefile drive the logic you could also run\nsuch a \"make test\" locally, which is something we should have\nanyway. E.g. when I build my own git I run the subtree tests, and would\nlike to eventually make \"run contrib tests too\" some configurable\noption.\n\nSo it is exactly the DRY principle. By avoiding making things needlessly\nCI-specific we can just control this behavior with flags, both in and\noutside CI.\n\n> In other words, I have fundamental objections about the approach and about\n> tying it to the patches that improve the output of Git’s CI/PR runs.\n\nI would too if after my series you needed to patch every place we run\n\"make test\" or whatever to run your subtree tests, but as noted above\nthat's not the case. So hopefully this addresses that.\n\nMore generally: I noted a while ago that if you pointed out issues like\nthat I'd be happy to address them for you.  Based on this I see\nd08496f2c40 (ci: run `contrib/subtree` tests in CI builds, 2021-08-05),\nand that would be easy to generalize.\n\n>> In Chrome/Firefox the time to load the page (as in the spinner stops,\n>> and we \"focus\" on the right content) is:\n>>\n>>     JS: ~60s / ~80s\n>>     Æ: ~25s / ~18s\n>\n> My focus is on the experience of occasional and new contributors who need\n> to investigate test failures in the CI/PR runs. In this thread, we already\n> discussed the balance between speed of loading the page on the one hand\n> and how well the reader is guided toward the relevant parts on the other\n> hand.\n\nFirst, your re-roll claims thta it \"improves the time to load pages\",\nbut based on the sort of testing I'd done before when I reported the\nsevere slowness introduced by this topic I can't reproduce that.\n\nSo how exactly are you testing the performance of these load times, and\ncan you share the numbers you have for master, your previous iteration\nand this re-roll?\n\n> I disagree with you that the former should be prioritized over the\n> latter, on the contrary, guiding the readers along a path to success is\n> much more important than optimizing for a quick page load.\n\nI think a better UX is certainly worth some cost to load times, so I'm\nnot trying to be difficult in saying that this costs us some\nmilliseconds so it's a no-go.\n\nBut really, this is making it so slow that it's borderline unusable.\n\nThe main way I use this interface is that I'll get an E-Mail with a\nfailure report, or see the \"X\" in the UX and click through to the\nfailure, then see the logs etc, and hopefully be able to see from that\nwhat's wrong, or how I could begin to reproduce it.\n\nRight now that's fast enough that I'll do that all in one browser\nclick-through session, but if I'm having to wait *more than a minute*\nv.s. the current 10-20 seconds (which is already quite bad)?\n\nYour latest series also seems to either be buggy (or trigger some bug in\nGitHub Actions?) where even after that minute you'll see almost nothing\non your screen. So a user who doesn't know the UX would end up waiting\nmuch longer than that.\n\nYou seemingly need to know that it's done when it shows you that blank\nscreen, and trigger a re-render by scrolling up or down, which will show\nyou your actual failures.\n\nThat's not an issue I saw in any iteration of this before this v3.\n\n> Most contributors who chimed in seemed to not mind a longer page load time\n> anyway, as long as the result would help them identify quickly what causes\n> the test failures.\n\nWasn't much of that discussion a follow-up to your initial demos of this\ntopic?\n\nI don't think those were as slow as what I'm pointing out above, which I\nthink is just because those failures happened to involve much fewer\nlines of log. The slowness seems to be at correlated with how many lines\nwe're dealing with in total.\n\n> Besides, the page load times are only likely to become\n> better anyway, as GitHub engineers continuously improve Actions.\n\nSure, and if this were all magically made better by GH engineers these\nconcerns would be addressed.\n\nBut right now that isn't the case, and we don't know if/when that would\nhappen, so we need to review these proposed changes on the basis of how\nthey'd change the current GitHub CI UX overall.\n"},{"id":"455881","messageId":"220524.86pmk3w6ji.gmgdl@evledraar.gmail.com","threadId":"57297","inReplyTo":"d3db5252fb8601f59c48fcac0120e1e2bcc33e03.1653171536.git.gitgitgadget@gmail.com","subject":"Re: [PATCH v3 08/12] ci(github): skip the logs of the successful test cases","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-05-24T10:47:41Z","receivedAt":"2022-05-24T10:48:08Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, May 21 2022, Johannes Schindelin via GitGitGadget wrote:\n\n> From: Johannes Schindelin <johannes.schindelin@gmx.de>\n> [...]\n> Co-authored-by: Victoria Dye <vdye@github.com>\n\nMissing SOB here for Victoria.\n\n> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> ---\n"}]}