You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
seankelly
changed the title
Make the lang and dist/os Travis options useful
Make the language and dist/os Travis options useful
Sep 16, 2016
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.
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: windowslanguage:
- python27
- python36script:
# a build script for a python software
or
os: windowslanguage:
- java8script:
# 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: windowslanguage:
- python27
- python36requirements: vs2017, curl, 7zipscript:
# a build script for a python software that needs Visual Studio 2017, curl and 7zip
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.
The text was updated successfully, but these errors were encountered: