CODEWITHSUNDEEP
environment-variablestravis-ci
yurisich
yurisich

Reputation: 7109

Skipping parts of a Travis job if building from a fork

I've been writing some shell tasks that can't run unless there are secure environment variables present in a Travis CI PR build. There is an auth token that must be present to push some information up about the build, so for builds originating from forks, I'd like to simply skip these parts. They're not critical.

How can I tell if a build is originating from a fork?

From the documentation around "Environment Variables":

TRAVIS_SECURE_ENV_VARS: Whether or not secure environment vars are being used. This value is either "true" or "false".

This is a little ambiguous. Does it mean that secure environment variables are being used anywhere (as in, present in .travis.yml)? That they are being exported as environment variables in the current build? I'm not sure this is a good way to guarantee that I'm testing a pull request that has originated from a fork, but I didn't see any other way to do it.

My first attempted had code that looked something like

[ ${TRAVIS_SECURE_ENV_VARS} = "false" ] && exit 0; # more shell code here...

but this appears to continue ahead and push up without an auth token, failing the task (and the build). Further complicating matters is that should the command fail, the output may contain the auth token...so everything from stderr and stdout is redirected to /dev/null. Considering that builds don't start for several minutes, I'm stuck waiting in a long debug cycle.

My next attempt simply bypassed this built-in environment variable, in favor of instead trying to grab a secure environment variable directly.

[ ${ghToken} -n ] && exit 0;

This fails in the same way as above. I'm beginning to wonder if [ $COND ] && exit 0; really works the way I'm expecting it to in this context. It seems to work just fine when I run equivalent shell scripts locally (Mac OSX and bash).

Does Travis offer a built-in way to determine if the pull request being built originated from the original repository versus a fork?

Here is my current work around.

screenshotsClone: {
    command: ['[ ${ghToken} ] &&',
              'git submodule add -f', screenshotPullTemplate, 'screenshots > /dev/null 2>&1;'].join(' '),
    options: {
        stdout: false,
        failOnError: false
    }
}

I'd rather not silently pass on errors should there be a legitimate problem with the shell task. At this point I might as well remove the environment variable check that precedes it.

Upvotes: 2

Views: 862

Answers (2)

yurisich
yurisich

Reputation: 7109

Stop using grunt-shell for things in your .travis.yml. Put those shell tasks into their own files so that you can stop using /bin/sh and start using /bin/bash, which is what you've been testing against locally.

Something like this will fix your problems.

Don't forget to mark the shebang as #! /bin/bash, which is crucial for the kinds of checks that should be happening on Travis.

Upvotes: 2

Dominic Jodoin
Dominic Jodoin

Reputation: 2538

I think what you want is to check if one of your secure environment variables is null to detect that you are running a build from a fork and in that case stop the build script prematurely.

Hence I would suggest you use the -z comparison operator in BASH to detect null strings because the -n operator detects non null string. A non null secure environment variable would mean that you are not running the build from a fork.

My suggestion is to change your line for:

[ -z "${ghToken}" ] && exit 0;

Hope this helps.

Upvotes: 1

Related Questions