Travis incorrectly double-quotes environment variables

Travis CI Discussions & Feedback
1

See https://travis-ci.org/lballabio/QuantLib/jobs/660190388.

I have quoted environment variables in my yml, such as for instance

env:
  global:
    - DOCKER_OPTS="--rm -ti -v ${HOME}/.ccache:/root/.ccache -v ${TRAVIS_BUILD_DIR}:/build -w /build"

As of this afternoon, the build started putting another pair of quotes around that (see line 435 in the job above) resulting in

$ export DOCKER_OPTS=""--rm -ti -v ${HOME}/.ccache:/root/.ccache -v ${TRAVIS_BUILD_DIR}:/build -w /build""

where the original quotes and the additional ones cancel out and leave the tokens unquoted.

Thanks,
Luigi

4 Likes
2

Iā€™m seeing single quotes getting doubled up too, which is breaking our builds in a script that does

for package in $@

You can see here that the quotes are being passed through rather than being interpreted by the shell: https://travis-ci.org/boutproject/BOUT-dev/jobs/660107324#L858

3

Another instance of this is the Travis environment variables that should be unset/empty are actually set to '' now, as if set by VAR="''", hence the

${TRAVIS_PULL_REQUEST_BRANCH:-$TRAVIS_BRANCH}

fails to evaluate to default all around the place.

4

Same situation, this code fails now, when tag is empty - if [[ "$TRAVIS_TAG" != "" ]]; then npm --no-git-tag-version version ${TRAVIS_TAG:1}; fi

5

Weā€™re having this problem too. All our builds are broken.

6

Just encountered this issue with our builds as wellā€¦

7

It is actually undocumented in https://docs.travis-ci.com/user/environment-variables/#global-variables whether itā€™s legal to pre-quote values ā€“ thus neither behavior is tested for.

A workaround right now for those affected is to remove quotes.

The syntax doesnā€™t make it clear whether the value is expected to be treated as a Bash expression or as a raw value ā€“ so Iā€™m not sure what the ā€œintuitiveā€ behavior would be.

8

FWIW, removing quotes does not restore the old behavior. Tried it in https://github.com/nipy/nibabel/pull/895, and variables with spaces were not set correctly.

1 Like
9

I guess we shouldnā€™t touch the value if there are any kind of outer quotes.

But then how to deal with the smarty-pants who would write smth like this?

- VAR=abc"$foo"'$bar'baz
10

Iā€™m not sure you need to catch every corner caseā€¦ People are motivated to find a way to get the strings they want into their variables. Unless youā€™re worried about some kind of code injection, I would be inclined to let things like that fail.

Iā€™m not personally invested in the quote syntax (apart from the time Iā€™ll have to spend if we move away from the old style), just as long as I can get spaces and interpolate previously-defined variables. Iā€™d rather not have to escape spaces, but if thatā€™s whatā€™s required, so be it.

11

Most likely an issue arising from


which was later reverted by

If applicable, you can restart the affected build(s)/job(s).

3 Likes
12

Youā€™re right, it seems to be working correctly now.

2 Likes