Make the language and dist/os Travis options useful

[seankelly]

The Travis file has options for the language and either os or dist to use. It would be good for people to be able to utilize these and Buildbot to map those options to whatever needed internally to effect what is expected. It is unclear to me at the moment if the os or dist option is the correct one to use. I am going to use os from now on for simplicity.

As an example, if using Docker, the os option could point to a higher-level option such as "trusty" or "xenial" and then Buildbot would map that to what the Docker worker needs in order to use a container for that OS. I think if an unknown option is used, the build for that OS should not be triggered and instead fail.

A similar thing for the language. There could be variants for the OS that include packages specific for that language so the basic tools do not have to be installed.

[tardyp]

You can already use the renderable image for that matter.

My goal is to keep buildbot_travis simple, so we need to figure out a programing model that is very simple yet powerful

[seankelly]

I have some code for this. What I did first was expose the os, dist, language, and what version the language is using as properties. Then I added a key that looked up the os, dist, and language to set properties for the build.

[vdsbenoit]

I upvote this feature request.

Simple way

IMO, a good way to keep it simple would be to have "os" and "language" fields in the Docker worker configuration. When a build is run, buildbot would choose a matching worker configuration.

Here is a mockup:

For instance, this worker would be used with the following yml file:

os: windows

language: 
  - python27
  - python36
  
script:
  # a build script for a python software

or

os: windows

language: 
  - java8
  
script:
  # a build script for a java software

Extended way

A more extended idea would be to add field named "requirements" or "labels". This field would hold elements that are also involved in the worker selection.

Here is an example:

This worker would be used with the following yml file:

os: windows

language: 
  - python27
  - python36
  
requirements: vs2017, curl, 7zip
  
script:
  # a build script for a python software that needs Visual Studio 2017, curl and 7zip