`script` deploy isn't parsed correctly with multiline

Travis CI Discussions & Feedback
, ,
1

When using multiline (clip style, so keeping last newline) to define deploy.script, it fails because it interpret the last \n as n.

language: minimal
deploy:
  provider: script
  script: >
    test a = a

It should work, but the actual execution is test a = an which fails the build.

2

It should not. With your configuration, the script value contains: test a = a\n, which fails.

There are many ways to define multiline strings in YAML; > retains the trailing newline. If you don’t want it, choose the one that trims it, for example:

deploy:
  provider: script
  script: >-
    test a = a
3

With your configuration, the script value contains: test a = a\n , which fails.

Yup, then it should get feed to a shell which would interpret \n as a field separator but travis is interpretting before feeding it thus transforming the newline to a letter.

Okay, so let’s take another example

language: minimal
script: >
  test an = a

By using your argument, it should work, given test an = a\n, but the actual execution is test an = a which fails the build.

My point is that parsing differently depending on the local context is kinda weird/buggy/probably wrong.

4

How do you argue that an and a\n are equal? One contains n (ASCII 110) and the other, newline (ASCII 10).

5

–

I’ll try to be more precis then, I reformulate:
In the context of a travis build, using the script deployer, after parsing YAML, we have two cases: either, the string parsed is ended by a newline or not. If not, it works as wanted. When it’s ending by a newline, the travis build system, probably when generating the build.sh, transform the newline to the letter ‘n’.

To show that, the next travis.yml actually fails

language: minimal
deploy:
  provider: script
  script: >
    true

It should work because

  • printf 'true' | sh returns 0
  • printf 'true\n' | sh returns 0