Conditions based on TRAVIS_* env vars do not work

We would like to distinguish public Travis and Travis@IBM in order to work around some differences in setup. I tried to do that with a condition in the jobs, e.g.:

if: env(TRAVIS_APP_HOST) =

I can see that this variable is set differently in Travis@IBM. However, the condition does not evaluate to true even on the public Travis, presumably because it is not yet set at the time and on the node where the conditions are evaluated.

  • Is there a way currently to distinguish Travis environments (such as public Travis and Travis@IBM) in conditions on jobs?

  • If not, could you please add that?

  • I did not find a clear description as to which environment variables can be used in conditions on jobs. Could you please add that to the docs?

Example build:

1 Like

The conditions are evaluated before any of the run time code is executed. As such, they cannot use environment variables that are assigned at the run time. This is explained in

Note that this means conditions do not have access to the build environment, and they are NOT evaluated in Bash. Bash variables or subprocesses can NOT be evaluated. Variable names and unquoted strings starting with a dollar char $ raise a parse error, causing the build request to be rejected. Quoted strings still can start with a dollar char, so if you definitely need a string to start with a dollar char you can enclose it in quotes.

Thanks for the link to the docs - I missed that part. This answers my last question.

As to my first question, I assume there is no way currently how Travis environments can be distinguished in conditions.

Can the version of Travis be detected in a condition, or the supported values for ‘os’ (that’s where the difference really is, in my case)?

Just for completeness, I have found this workaround that relies on the two environments having different versions (currently):

- # Travis@IBM
  if: false  # ignored by Travis@IBM
  os: linux-s390
  language: python
  python: "3.8"
    - ARCH=s390x  # just for displaying in build listing

- # Public Travis
  arch: s390x  # ignored by Travis@IBM, so it runs default arch
  os: linux
  language: python
  python: "3.8"

Are you saying that a single repository is triggering builds on and the Enterprise installation at IBM?

No. The Travis@IBM is driven only from the GitHub@IBM, and the public Travis is driven only from the public Github.

We have two copies of the repo, and the repo on the internal Github is used to develop features that need to stay internal before we can move them out to the public GitHub, e.g. during the time when a new s390x machine generation is developed but not yet announced.

What I want to achieve though is to have exactly the same files in both repos to minimize the syncing, and so I am trying to use the same .travis.yml file in both repos. Because the internal Travis is still at an older version, it does not yet have the ‘arch’ item in the job, and it also does not yet support ‘if’ at all. The os=linux-s390 was basically a workaround our Travis admins came up with, and these differences now cause two paths in my .travis.yml file.

The goal would be that I can define a job that only runs on Travis@IBM, and a job that only runs on the public Travis (due to the difference in the ‘os’ value). I am achieving this goal half-way: On the public Travis, I run only the desired job, but on the internal Travis, the job for the internal Travis runs with arch s390x but the job for the public Travis also runs unintendedly (ignoring the ‘arch’, so it runs on AMD64). That’s as good as it gets right now, I think.

Of course, I do understand that the best solution would be that the internal Travis gets upgraded, but I need to find a solution for our project now (and I’m working with our Travis admins on the upgrade question).

I’m happy enough with this workaround that I don’t need a way to distinguish the Travis installations anymore (they are distinguished by the support for ‘if’ :slight_smile: ).

1 Like