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

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.

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).

12

You’re right, it seems to be working correctly now.