travisci

Travis CI

Grundlagen

• travis-ci.org listet alle persönlichen public github repos auf
• getestet wird aktuell auf Ubuntu 12.04 LTS VM´s
• hinzufügen eines Repositorys:
  • aktivieren auf der travis-ci Website
  • hinzufügen eines .travis.yml Configfiles
  • pushen eines neuen Commits

Build Lifecycle

• Build Configuration - Documentation - Travis CI
• Travis CI Build Lifecycle

Build Stages

Wenn ein Befehl innerhalb der Stages before_install, install oder before_script einen exit-code != 0 zurückgibt wird der Build als errored gekennzeichnet. Innerhalb der Stufe script als failed.

1. before_install

hier können zusätzliche Abhängigkeiten des Projekts wie z.B. Ubuntu Packages oder custom Services installiert werden.

Use this to prepare the system to install prerequisites or dependenciese.g. sudo apt-get update

2. install

Use this to install any prerequisites or dependencies necessary to run your build

Wenn man diesen Schritt überspringen will dann geht z.B.

install: true

3. before_script und after_script

Hier kann der Build auf das Testen vorbereitet werden bzw. after_script läuft direkt nach dem Test. In diesen Stages sind mehrere Befehle erlaubt:

before_script: some_command
after_script:  another_command

bzw.

before_script:
  - before_command_1
  - before_command_2
after_script:
  - after_command_1
  - after_command_2

before_script

Use this to prepare your build for testing e.g. copy database configurations, environment variables, etc.

4. script

Default is specific to project language

Hier findet der eigentliche Test statt. Wenn diese Stage nicht explizit in .travis.yml konfiguriert wurde, tritt ein sprachspezifischer default in Kraft. z.B. werden node.js standardmäßig via npm test getestet. Man kann hier z.B. scripte ausführen. Beispiel:

script: ./script/ci/run_build.sh

oder

script: "./run-tests.sh"

Wenn diese mit einem exitcode 0 abschließen dann war der Build erfolgreich. Das heißt hier kann man alles mögliche zum Testen verwenden.

5. after_success or after_failure

• Sachen die getan werden sollen wenn der Build erfolgreich war oder failed
• after_success wäre z.B. Dokumentation generieren, deployen
• after_failure wäre z.B. Logs wegschicken

das .travis.yml file

• .travis.yml file basics
• hier wird das sprachspezifische Buildverhalten definiert

Beispiel:

    language: node_js
    node_js:
      - "0.10"
    before_install:
      - "curl -L http://git.io/3l-rRA | /bin/sh"
    services:
      - mongodb
    env:
      - LAIKA_OPTIONS="-t 5000"

Neben den Stages gibt es hier noch weitere Optionen.

services

Services & Database setup - Documentation - Travis CI

env

Travis CI: Environment Variables - Documentation

notifications

Hier können Benachrichtigungen konfiguriert werden. Travis CI: Configuring Build Notifications - Documentation

z.B:

• E-Mail
• IRC
• HipChat

Laika

• [JavaScript (with Node.js) - Documentation - Travis CI](http://docs.travi- s-ci.com/user/languages/javascript-with-nodejs/)
• Unit Tests kann man via Laika - Testing Framework for Meteor durchführen

Unit Testing Framework für meteor Apps. Das hier scheint ein guter Einstieg zu sein: Meteor.js in Action: Create an App, Test with Laika - Michael Herman ...

Vorraussetzungen

• für Laika-Tests legt man einen Ordner /tests an. In diesem werden die Tests ausgeführt.

Konfiguration in Travis CI

language: node_js
node_js:
  - "0.10"
before_install:
  - "curl -L http://git.io/3l-rRA | /bin/sh"
services:
  - mongodb
env:
  - LAIKA_OPTIONS="-t 5000"

Beispiel

Test Driven Development with Meteor - SitePoint

Was mir zu Laika fehlt ist ne ordentliche Dokumentation. Es soll wohl auf mocha aufgebaut sein, aber Ich hab jetzt noch nicht wirklich was zu der Syntax hier gefunden. Zumindest zum Emitter-Pattern gibt es hier was: Node.js Events and EventEmitter - SitePoint

var assert = require('assert');

suite('Posts', function() {
  test('in the server', function(done, server) {
    server.eval(function() {
      Posts.insert({title: 'hello title'});
      var docs = Posts.find().fetch();
      emit('docs', docs);
    });

    server.once('docs', function(docs) {
      assert.equal(docs.length, 1);
      done();
    });
  });
});

Fragen

• wie sinnvoll ist welche Integration?
  • nur builden (wenn ja wie?)
    • meteor build testet nichts, es packt nur zusammen
  • Unit Tests?