I have reported your question to the appropriate engineering team for further evaluation. The team will review the feedback and notify me about the next steps. I will update here in time. Thank you for your understanding.

Sorry, I just noticed your reply!

Thanks very much for this, it resolves the issue.

It took me an hour to realize that multi-line strings were the issue for me, and then a few more hours to find this solution.

It would be great if multi-line strings as values could be better supported, and documented.

Here are a few observation. First, it is important to suppress word-splitting upon expansion in bash. This is easiest done by enclosing with double quotes:

REPORT="$(cat logfile)"

Similarly, word splitting also has to be suppressed when reading back:

echo "$REPORT"

The double quotes are necessary.

However, Workflows gets confused/truncates when dealing with an expanded multi-line value:

echo "::set-env name=REPORT::$REPORT"

This does not work for multi-line variables.

The solution above uses a standard bash feature to expand and substitute characters:

REPORT="${REPORT//'%'/'%25'}"REPORT="${REPORT//$'\n'/'%0A'}"REPORT="${REPORT//$'\r'/'%0D'}"

This essentially makes the value into a single line string.

The github engineers then also knew that when reading back the variable in the workflow these escape values get substituted back to the actual characters:

${{ env.REPORT }}

This results actually in a multi-line string. Unfortunately, this is not documented anywhere and comes across a bit as magic. If there are other substitutions it would be good to also document those.

Thanks so much posting this. I came across the same issue and found this rather obscure solution, after a lot of trial and error.

A couple observation dealing with multiline values, mostly as a reminder on how this works.

If using bash, it is important to suppress word splitting upon parameter expansion, to keep the line breaks. It is easiest with double quotes:

REPORT="$(cat log.out)"

Accessing the variable also invokes word splitting, which needs to be suppressed:

echo "$REPORT"

However, set-output or set-env does not work with expanded multiline values:

echo "::set-env name=REPORT::$REPORT"

This does does not work, as Workflows somehow truncates or ignores the value.

The solution above is to escape the newlines and other apparently unhandled characters using bash expansion and substitution. This makes the value effectively single line.

The thing to notice is that Workflows substitutes the escaped characters back when the parameters is used in ${{ }}:

body: |  eslint and diff report:  ```  ${{ env.REPORT }}  ```

Here the final value includes actual newlines.

It would be great if this behaviour cold be documented somewhere. For example, are there other substitutions happening ?

@andreasplesch  Thank you for your further investigation. I would recommand you to create an issuein the action toolkit repo . You could ask for adding an example forset-env andset-output with multiline values inthis document. 

Thanks. Good to know that there is more in depth documentation available in the toolkit repo. I think a link from the main help page athttps://help.github.com/en/actions to this documentation could be helpful.

Hm, it looks like newlines should already be escaped automatically:

https://github.com/actions/toolkit/blob/master/packages/core/src/command.ts#L76

Anyways, here is the new issue in the repo:

actions/toolkit#403

and a related issue:

actions/toolkit#193

Escaping of special characters already happened for javascript actions but does not for bash scripts. There is a plan to update documentation.

I have bumped into this exact issue, and found another solution: we can usejq to do the conversion into a valid JSON string for us, and then usefromJSON to unpack it again.

For example: the variable$mystr holds the (multiline) contents of filemyfile; we convert to a one-line JSON string withjq --raw-input --slurp '.', and then unpack in a later step.

-id:mysteprun:|    mystr=$(< myfile)    msg=$(printf '%s' "$mystr" | jq --raw-input --slurp '.')    echo "::set-output name=msg::$msg"-run:|    echo "${{ fromJSON(steps.mystep.outputs.msg) }}"

Notice that this isn’t fool-proof, either: if the expanded string contains double quotes, theecho in the second step might get confused. Set the value as an environment variable to avoid.

I also have an issue where I would like to output a list of paths and other data only if the action processes multiple files (to push them tonuget.org or any nuget feeds).

Here is yet another potential work-around.

This is working in a CI Action job of mine, which takes the content of a text file that contains test results and posts the whole content (which is multiline content) back to the relevant PR as a comment. The resulting comment accurately reflects the original newlines of the test result output.

name: build_for_PR
on:
pull_request:
branches:
- main
jobs:
linux_publish_test_output:
runs-on: ubuntu-18.04steps:- uses: actions/checkout@v1- name: run_all_linux_ci  run: ./linux_build_all_and_test.sh- name: get_legacy_gui_test_output  id: legacy_out_01  run: echo "::set-output name=testconfout::$(cat path_from_my_git_root/to/build/artifacts/db_mgr_test_output.txt | python3 -c 'import sys; print(sys.stdin.read().replace("\\","\\\\").replace("\"","\\\"").replace("\n","\\n"))' )\n"- uses: actions/github-script@v3  with:    script: |      var theContent = "${{join(steps.legacy_out_01.outputs.*, '\n')}}";      github.issues.createComment({      issue_number: context.issue.number,      owner: context.repo.owner,      repo: context.repo.repo,      body: 'LEGACY GUI TEST OUTPUT (from most recent CI job on this PR):\n\n' + theContent      })

This was inspired by the approach posted by @bewuethr. As far as I can tell in a couple days of usage, the python-based solution I am sharing does manage to handle double-quotes in the text (in addition to newlines).

Thanks a lot for sharing, this unblocked me :slight_smile:

For completeness, I want to point out that you can also use an environment variable via environment files for multiline text:Workflow commands for GitHub Actions - GitHub Docs

steps:  - name: Set the value    shell: bash    run: |      echo 'JSON_RESPONSE<<EOF' >> $GITHUB_ENV      curl https://httpbin.org/json >> $GITHUB_ENV      echo 'EOF' >> $GITHUB_ENV  - name: Print multiline response    shell: bash    run: |      echo "$JSON_RESPONSE"

Has this been fixed? I built a function to work around this, and now it displays the escape sequences.

Here’s my multi-line output solution which requires no changing of the data, however you do have to write it to a text file first.

In this example I’m using it for stderr, but you can adapt it to any kind of multi-line output too

# on windows, powershell fails on stderr output and improperly# handles putting it in the file. It's required to run as cmd /c# if not using windows, then change this command appropriately- name: build  id: build  continue-on-error: true  run: cmd /c "build 2> errors.txt"
name: Set error-log to var
uses: actions/github-script@v4
id: error-log
if: steps.build.outcome != 'success'
with:
script: |
const fs = require('fs');
return fs.readFileSync('errors.txt','utf8').toString();
result-encoding: string
you can access the output variable in like so
name: Some action
uses: whateveryouwant/whatever@4
if: steps.build.outcome != 'success'
with:
something: ${{ steps.error-log.outputs.result }}
print errors.txt to stdout + fail workflow since build failed
usecat if not using windows
name: Show build errors
if: steps.build.outcome != 'success'
run: |
type errors.txt
exit 1

Note: You can change the output variable name by usingcore.setOutput as well.

For any lost souls in the future: If you’re setting output in a Docker container (like if your action is a .NET binary), not in the action YML, by just printing::set-output name=whatever::whatever, all you need to do to fix this is replace any\n you have with%0A

Also for anyone in the future with this issue, I JSON-encoded the content I needed to put intoGITHUB_ENV like so:

cat_results=$(cat results/results_blob.txt | python3 -c 'import json; import sys; print(json.dumps(sys.stdin.read()))')echo "RESULTS=${cat_results}" >> $GITHUB_ENV

I kept getting errors with the multiline$GITHUB_ENV. This worked perfectly since I wanted the content JSON-encoded anyway. It was sent over the Github API to create a comment on a PR. You can decode the JSON in another step rather than hoping you caught all url-encoded characters withreplace().

Wow, I had this problem for a year and I couldn't solve it. I believed this one the problem with slack action that wasn't supporting multiline comments. Now I have finally found this thread and found a solution for a problem in my script that existed more than a year

For future reference:
WithGitHub's newGITHUB_OUTPUT file, multiline outputs don't need to be escaped anymore. They simplyneed to use a delimiter:

delimiter="$(openssl rand -hex 8)"echo"output-name<<${delimiter}">>"${GITHUB_OUTPUT}"echo"Some\nMultiline\nOutput">>"${GITHUB_OUTPUT}"echo"${delimiter}">>"${GITHUB_OUTPUT}"

Note I'm usingopenssl rand -hex 8 to get a unique delimiter as suggested in the docs.