There are many programming languages out there, and Travis CI would like to support as many as possible.
However, the Travis CI team often lacks the expertise to make this a reality. This is where the community-supported languages come in.
What does ‘community-support’ mean?
The community-supported lanugages are those programming languages the support of which is provided by self-identified experts in the langugages’ respective community.
Following the process described below, your favorite language could be the next community-supported language on Travis CI!
Process to add a new community-supported language
- Gather a group of 3 or more volunteers versed in the desired language to provide support.
- Create pull requests (details below).
- Work with Travis CI team to get the PRs production-ready.
- Provide ongoing support for the issues involving the language.
A group of 3 is a minimum to support a language. This allows redundancy in providing support when a member of the support team is unavailable.
There are a few repositories (only travis-build is required) that realize support for builds in a new language.
This is the only repository required to support the new language.
Create a new class, inheriting from
Travis::Build::Script, that implements reasonable defaults for your language’s build stages.
A basic build follows these stages:
There are other phases that can be customized for a particular language; the Travis CI team will work with you to identify and implement the customization if you think it is appropriate to do so.
In container builds the
configurephase still has
sudoaccess, but subsequent phases do not, so if you need to use
sudoto set up your language environment, for example to install packages, do that in
If you want to support build matrix expansion based on various language versions (e.g., Ruby 2.2, 2.1, etc.), and you wish to add a convenient way to restrict deployments based on the language version, add your language to
If you want to support build matrix expansion based on various language versions (e.g., Ruby 2.2, 2.1, etc.),
travis-coreneeds to know about it.
Build::Config::ENV_KEYSdefines which keys are possible matrix dimensions, and
Build::Config::EXPANSION_KEYS_LANGUAGEdefines which keys among the possible ones are actually expanded based on the
This PR is a straightforward example.
If the language provides build matrix expansion, it would be nice to have this information visible to the end user.
To make this happen, you need to tell
travis-webto pick up the value from the job’s data and display it. Clone the
travis-webrepository, add your language to the
app/utils/keys-map.coffeefile and submit a pull request for this change.
It is important to note that languages are configured at build time, thus components are downloaded every time a job runs.
To save build time, you should limit your language resource usage to a minimum.
Testing will be done in our staging environment, which, at the moment, is a shared resource. As such, testing the proposed changes could take some coordination between you and the Travis CI team.
Testing your code locally
Optionally, you can use
travis-build as an addon
to the CLI utility.
This allows you to compile the
travis-build code you are working on
into a Bash script, which you can then check for correct syntax (
bash -n) and
execute (we recommend doing this on a virtual machine) to aid your development.
List of community-supported languages
In alphabetical order, they are: