On Fri, Jun 03 2022, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>>> Further, since this failure is outside of any `test_expect_success` or
>>> `test_expect_failure`, the error message about this is not even included
>>> in the weblogs (but of course it is included in the full logs that are
>>> included in the build artifacts). For the record, here is the error
>>> message:
>>
>> ...this part of it though seems like a pretty bad regression in your
>> merged-to-next js/ci-github-workflow-markup topic, which just happens to
>> be unearthed by this CI failure.
>
> Indeed it makes it impossible to figure it out things like this
> case. But ...
>
>> But this does look easy to "solve" with a quicker fix, just bringing
>> back the "ci/print-test-failures.sh" step so you can at least expand it,
>> and not have to go to the "summary" and download the *.zip of the log
>> itself. As that shows we still have the raw log there, it just didn't
>> make it to the new GitHub Markdown formatting mechanism.
>
> ... it seems a solution is possible? Care to send in a patch (or
> perhaps Dscho already has a counter-proposal)?
The only thing I have at the moment is:
1. git revert -m 1 bd37e9e41f5
2. merge: https://lore.kernel.org/git/cover-v6-00.29-00000000000-20220525T094123Z-avarab@xxxxxxxxx/
3. merge: https://lore.kernel.org/git/cover-v6-00.14-00000000000-20220525T100743Z-avarab@xxxxxxxxx/
I.e. to pick this in the sequence I'd proposed doing & have tested
thoroughly.
It also addresses other noted some other regressions in "next", but as
noted e.g. in [A] there's other issues in "next", e.g. that even the
"raw" trace logs are altered as a side-effect of running with
--github-workflow-markup, and of course the major UX slowdowns.
So I think the better way forward would be to do that & leave out [B],
i.e. make the new output format optional, and wait until outstanding
issues are fixed until we flip the default.
But do I have something that neatly fixes the issue(s) on top of "next"
without a revert & re-apply? No, sorry.
In case you want to go for that the resolution for [2] is [C], and a
"git rm ci/run-build-and-tests.sh ci/run-static-analysis.sh".
A. https://lore.kernel.org/git/patch-v6-13.14-fbe0d99c6b3-20220525T100743Z-avarab@xxxxxxxxx/
B. https://lore.kernel.org/git/patch-v6-14.14-0b02b186c87-20220525T100743Z-avarab@xxxxxxxxx/
C.
diff --git a/Makefile b/Makefile
index 19f3756f7eb..c2b0a728df5 100644
--- a/Makefile
+++ b/Makefile
@@ -3618,3 +3618,4 @@ ci-static-analysis: ci-check-directional-formatting
ci-static-analysis: check-builtins
ci-static-analysis: check-coccicheck
ci-static-analysis: hdr-check
+ci-static-analysis: check-pot
diff --git a/ci/lib.sh b/ci/lib.sh
index 80e89f89b7f..9c54c1330e6 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -270,7 +270,7 @@ linux-TEST-vars)
setenv --test GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS 1
setenv --test GIT_TEST_MULTI_PACK_INDEX 1
setenv --test GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP 1
- setenv --test GIT_TEST_ADD_I_USE_BUILTIN 1
+ setenv --test GIT_TEST_ADD_I_USE_BUILTIN 0
setenv --test GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME master
setenv --test GIT_TEST_WRITE_REV_INDEX 1
setenv --test GIT_TEST_CHECKOUT_WORKERS 2
