k1LoW / runn

runn is a package/tool for running operations following a scenario.
https://runn.run
MIT License
417 stars 30 forks source link

Include runner ignores values after newline in variable #920

Closed na3shkw closed 3 months ago

na3shkw commented 3 months ago

I'm using include runner to use other runbooks. When passing variables with multiline values using vars:, it seems that values after newline in variable are being ignored. This can be reproduced with runn version v0.107.1 using the following runbook and command.

parent.yml

desc: Parent runbook
steps:
  createMessage:
    exec:
      command: |
        cat <<EOF
        1st line
        2nd line
        EOF
  printMessageParent:
    dump: steps.createMessage.stdout
  sampleStep:
    include:
      path: child.yml
      vars:
        message: "{{ steps.createMessage.stdout }}"

child.yml

desc: Child runbook
vars:
  message: No message
force: true
steps:
  printMessageChild:
    dump: vars.message
  testShouldPass:
    test: vars.message == "1st line\n2nd line\n"
  testShouldFail:
    test: vars.message == "1st line"

Command and output result:

$ runn run --scopes run:exec --verbose parent.yml
=== Parent runbook (parent.yml)
    --- (createMessage) ... ok
1st line
2nd line

    --- (printMessageParent) ... ok
1st line
    --- (printMessageChild) ... ok
    --- (testShouldPass) ... fail
        Failure/Error: test failed on "Child runbook".steps.testShouldPass: condition is not true

        Condition:
          vars.message == "1st line\n2nd line\n"
          │
          ├── vars.message => "1st line"
          └── "1st line\n2nd line\n" => "1st line
              2nd line
              "

        Failure step (child.yml):
        8   testShouldPass:
        9     test: vars.message == "1st line\n2nd line\n"

    --- (testShouldFail) ... ok
        === Child runbook (child.yml)
            --- (testShouldFail) ... ok

1 scenario, 0 skipped, 1 failure

Looking at the results, it appears that vars.message is being interpreted as 1st line.

k1LoW commented 3 months ago

@na3shkw Thank you for your report!

This looks like a bug.