Subject: Re: js/ci-github-workflow-markup output regression

From: Junio C Hamano <[email-masked]>
Date: Tue, 07 Jun 2022 11:25:51 -0700

Ævar Arnfjörð Bjarmason <[email-masked]> writes:

> On Fri, Jun 03 2022, Junio C Hamano wrote:
>
>> 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/[email-masked]/
>     3. merge: https://lore.kernel.org/git/[email-masked]/
>
> I.e. to pick this in the sequence I'd proposed doing & have tested
> thoroughly.

I know you two have difference in opinions, but throwing away
everything the other party did and forcing your stuff in is not a
very effective way to work together.

> 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.

Dscho?  I know you do not care about the UX slowdown as much as
others, but I am sure you do not consider what is in 'next' is
perfect. It seems to need further work to go back to the feature
parity with what it replaced.