Multiline support for Toolkit Annotations

[svartalf]

This is a follow-up issue started at #186 (comment).

It is unclear from the recently added Annotation docs if ::debug/::warning/::error messages support multiline text in the {message} placeholder.

Why it is important? These Annotations can be used by various code linters and other similar tools, but their output easily could be spanned to multiple lines, for example:

pylint output:

W:108: Operator not followed by a space
     print >>sys.stderr, 'Unable to match %r', line
            ^

Rust compiler output:

warning: comparison is useless due to type limits
  --> example/src/lib.rs:20:8
   |
20 |     if pid < 0 {
   |        ^^^^^^^
   |
   = note: `#[warn(unused_comparisons)]` on by default

It would be nice to clarify if it is possible to use multiline strings over there and it is expected to be working correctly in the future.

[danechitoaie]

+1 At least some kind of initial feedback. Is it possible or not? And then maybe follow up with updating the docs.

[EricWF]

+1. This is one of the last blocking issues blocking me from moving to Github Actions. The output of my test suites failures are much longer than a single line, and I have no way to display them nicely.

[BrianHenryIE]

It can be achieved by using urlencoded newline %0A in place of \n.

I learned it from a comment by @PoisonousJohn at actions/starter-workflows#68 (comment)

I've confirmed it working for PHPUnit output and have a PR: https://github.com/mheap/phpunit-github-actions-printer/pull/14/files

And here's a screenshot of the outcome: https://i.imgur.com/nnSCPTG.png

Zero documentation anywhere, thank you @PoisonousJohn !

[EricWF]

I just discovered this, Cheers!
I can confirm it works and have used it successfully in a workflow.

PS. @BrianHenryIE Have you discovered a way to make problem matchers work with multi-line messages?

[Profpatsch]

Wow, such an important feature and the only way to solve it is via an undocumented hack.

Why not just use a json object printed on one line, which can be readily produced with e.g. jq? Is this the quality standard the Github Actions team wants to stay at?

[Fleshgrinder]

The same trick can be used in echo "::warning::multi%0Aline" commands within a workflow. This creates a multiline annotation, but only the first line in the build log is going to be highlighted, all that follows show up as normal.

[rhaschke]

The same trick can be used in echo "::warning::multi%0Aline" commands within a workflow.

Unfortunately, this trick doesn't work anymore:

[rhaschke]

The Command class (still) uses this escaping:

toolkit/packages/core/src/command.ts

Lines 80 to 85 in 7b617c2

	function escapeData(s: any): string {
	return toCommandValue(s)
	.replace(/%/g, '%25')
	.replace(/\r/g, '%0D')
	.replace(/\n/g, '%0A')
	}

[muzimuzhi]

@rhaschke It seems the %0A trick still works, see https://github.com/pgf-tikz/pgf/actions/runs/7294270657.

[rhaschke]

It seems the %0A trick still works, see https://github.com/pgf-tikz/pgf/actions/runs/7294270657.

For me, the multi-line output is only shown correctly when clicking "show more". Without that expansion, everything shows up in a single line, doesn't it?
In my example (with a shorter line) it doesn't work: https://github.com/rhaschke/test/actions/runs/5961263674
As the line(s) are too short, there is no "show more" button provided.

[muzimuzhi]

@rhaschke Yes, you observation is right.

[justinmchase]

The new lines (escaped with %0A) don't appear to be respected in the annotation view of the errors...

new lines are not displayed

raw logs show newlines correctly

Also, I definitely expected it to respect markdown but it does not, which is surprising.

[tsigouris007]

Is there any actual way that works here?
%0A does not work for me as well now.

[Ximaz]

I search for something similar but unable to find. I'd like to display valgrind's logs for memory leaks as an Error annotation, but it's multiline. I tried to do so :

-   name: "Analyze valgrind report"
    run: |
        status=0
        block=""
        while IFS= read -r line; do
            if [[ "${block}" != "" ]]; then
                if [[ $(echo "${line}" | grep '^==.*== $') ]]; then
                    echo "::error title=\"Valgrind Error\"::${block}"
                    block=""
                    status=1
                else
                    block="${block}
        ${line}"
                fi
            fi
            if [[ $(echo "${line}" | grep '^==.*== .* bytes in .* blocks are definitely lost in loss record .* of .*$') ]]; then
                block="${line}"
            fi
        done < valgrind-reports.log
        rm -f valgrind-reports.log
        exit "${status}"

And you can see that I'm leaving a line, without having to specify %0A, but the result is quite similar to the one above.

I think it would be cool to have a sort of ::group:: ::endgroup:: but making it working for error, warning and so on, so it also gets displayed on the workflow summary.

In fact, it appeared that %0A works, I mean, at least regarding the summary :

But when clicking on the details, other logs are still shown outside of the error scope.

[elliot-nelson]

To confirm @rhaschke observation above: the %0A character works, but only in the "Show More" view of an annotation long enough for the "Show More" link to show up. When an annotation is collapsed or is too short to require a Show More link, there is no character code or formatting that will display the multi-line message properly.

Hopefully, this is something GitHub can fix.

---

      - name: Test
        run: |
          echo "::error::Example of a short multi-line error%0Awith a few lines%0Aof text."
          echo "::error::Example of a long multi-line error%0Awith quite a few long lines of text that will end up%0Arequiring the Show More link to display the entire%0Aerror message in the GitHub Annotations pane,%0Awhich will display properly as a multi-line error."