Windows environment is actually Ubuntu when language is c or cpp

Environments Windows
,
#1

I’m debugging an unrelated issue on a Windows environment. I thought it was tied to running with language: shell so I changed it to language: c (also tried language: cpp) and the Windows environment is now actually an Ubuntu environment.

https://travis-ci.org/ssec/sift/jobs/660796880

I have os: windows and it was using Windows when language: shell was set. Any ideas?

#2

Hey @djhoese

Have you tried:

matrix:
  include:
    - os: windows
      language: bash

Just to change from sh to see if that makes a difference.

1 Like
#3

Hi @Montana,

bash and shell are meant to be the same thing on Travis right? I did switch it to bash and it did start a Windows container. I’m not sure what doing language: c should change for me inside the container, but I was hoping I could try it.

matrix:
  include:
  - env: PYTHON_VERSION=3.7
    os: linux
  - env: PYTHON_VERSION=3.7
    os: osx
    language: generic
  - env: PYTHON_VERSION=3.7
    os: windows
    language: bash
#4

Hm I changed a few things including commenting out the linux and osx environments, removing a PYTHON_VERSION=X global environment variable, setting language: c, and swapping the env: and os: lines in the Windows environment definition and that seems to make Travis use the Windows container correctly.

https://travis-ci.org/github/ssec/sift/builds/661073731

Sadly having the c language set doesn’t fix my DLL loading issues.

#5

@BanzaiMan,

Could be related to the default-value injection scheme?

#6

Not sure what you mean by that? It seems odd that the order of the keys should make a difference.

#7

@djhoese,

Sorry about that was asking a colleague given the nature of the problem, this thread is very similar, take a look: Windows build specified in matrix--being ignored and a default linux build is running instead

#8

hello,

@Montana method does finally build a windows container, I was having same issue it would default to linux based os

#9

That’s great news @SolarUltima,

I can’t be sure (what I am sure of is, this is a workaround I’ve found myself) but is not the core issue (obviously) I’ve tagged my colleague, he will get back to this situation, which from the looks of it may already be resolved.

To answer your question @djhoese, on the difference of bash and shell when coming from a build instructions angle, it still (from my experience) stays true to the scripting language in question.

A bash script is a script interpreted and executed by the bourne again shell, and is from that, it is a shell script.

Hope that clears some of the confusion up for you. I’m hoping this is resolved, if it isn’t I will be sure to take it directly to support and keep you posted every step of the way @djhoese.

-Montana (Travis CI Staff)

#10

This is either resolved on the Travis side or was “fixed” by me re-ordering the env and os keys.

I’m aware of the sh shell, the bash shell, other shells, and their differences. What wasn’t clear what difference I should expect by using your suggestion of language: bash versus my original language: shell. Especially since the documentation makes it seem like they both can be used to tell Travis “I want a bash environment”. Regardless, it’s all good now it seems.

Imprint