Specification for lifecycles file

Generic format

This is the general description of the supported language format listing default commands. This will be used to generate default commands depending on the language and files detected in the repository.

language:
  friendlyName: my friendly name
  defaultKey: somekey
  somekey:
    fileExistsCondition: somefile
    fallbackKey: some other key
    env: export somevar=value
    before_install: some command
    install: some command
    before_script: some command
    script: some command
    after_success: some command
    after_failure: some command
    after_script: some command
  some other key:
    install: some command
    script: some command

Generic format Legend

1. language - is the language that the commands are set up for. e.g. groovy, python, ruby, java, etc. The language is the root key of the object and will be used to look up default commands for all of the different command generation cases. The following keys fall under the language. Validation: This key is required.
   1. friendlyName - A friendly name which can be used to reference the language. This is sometimes different than the key used to reference the language. Provides a user friendly means of printing out the language being used. e.g. Instead of cpp it is C++. Validation: This key is required.
   2. defaultKey - This is the default key which will be used to look up the default commands to be generated. Validation: This key is required. The value of this key must exist as another key in the same level as this key. e.g. "somekey".
   3. somekey - This key is one or more keys in which will, by convention, be named after the build tool the commands are related to. e.g. gradle, ant, maven, etc. Validation: This key is required if it is referenced by any other keys (i.e. referenced by defaultKey or a fallbackKey).
      1. fileExistsCondition - If fileExistsCondition key does not exist then jervis uses the default commands in this parent key. If fileExistsCondition key does exist AND the file exists then jervis uses the default commands in this parent key. If fileExistsCondition key does exist AND the file does not exist then it will use the fallbackKey to try to fall back to another key. If fileExistsCondition key does exist AND the file does not exist AND fallbackKey does not exist then jervis uses the default commands in this parent key. Validation: This key is optional. This key is required if fallbackKey exists.
      2. fallbackKey - Reference a key that the program should fall back to for other defaults. Validation: This key is optional. If this key exists then the fallback key, "some other key", must exist. fileExistsCondition becomes a required key if this key is used.
      3. env - Used to set any environment variables which will be included before the before_install step is executed. Validation: This key is optional.
      4. before_install - The contents of this key may either be a string of commands to execute (one line). Validation: This key is optional.
      5. install - The contents of this key may either be a string of commands to execute (one line). Validation: This key is optional.
      6. before_script - The contents of this key may either be a string of commands to execute (one line). Validation: This key is optional.
      7. script - The contents of this key may either be a string of commands to execute (one line). Validation: This key is optional.
      8. after_success - The contents of this key may either be a string of commands to execute (one line). Validation: This key is optional.
      9. after_failure - The contents of this key may either be a string of commands to execute (one line). Validation: This key is optional.
      10. after_script - The contents of this key may either be a string of commands to execute (one line). Validation: This key is optional.

These are similar in concept to the Travis Build Lifecycle.

A more specific formatted example

Here's an example of our supported language key when we're supporting just the groovy language. This example is based on the "Building a Groovy Project" Travis CI Documentation. In the groovy project docs it first tries gradle, then falls back to maven, and finally falls back to ant. The following represents that.

groovy:
  friendlyName: Groovy
  defaultKey: gradle
  gradle:
    fileExistsCondition: build.gradle
    fallbackKey: maven
    install: gradle assemble
    script: gradle check
  maven:
    fileExistsCondition: pom.xml
    fallbackKey: ant
    install: mvn install -DskipTests=true
    script: mvn test
  ant:
    script: ant test

An example with two supported languages

Now we're going to add another language, ruby, to the previous example. This example is based on the "Building a Ruby Project" Travis CI Documentation.

groovy:
  friendlyName: Groovy
  defaultKey: gradle
  gradle:
    fileExistsCondition: build.gradle
    fallbackKey: maven
    install: gradle assemble
    script: gradle check
  maven:
    fileExistsCondition: pom.xml
    fallbackKey: ant
    install: mvn install -DskipTests=true
    script: mvn test
  ant:
    script: ant test
ruby:
  friendlyName: Ruby
  defaultKey: rake1
  rake1:
    fileExistsCondition: Gemfile.lock
    fallbackKey: rake2
    install: bundle install --jobs=3 --retry=3 --deployment
    script: bundle exec rake
  rake2:
    install: bundle install --jobs=3 --retry=3
    script: bundle exec rake

The groovy and ruby language keys are independent of each other. It depends on the language: groovy or language: ruby setting in the .travis.yml.