QVINTVS · SCRIBET

ChiliProject und Activities

Wem schon einmal aufgefallen ist, dass ChiliProject im Reiter “Activity” (in der deutschen Version “Aktivität”) nicht immer auf dem neusten Stand ist, d.h. die neusten Commits nicht anzeigt, könnte sich für diesen Artikel interessieren.

Der Grund für dieses Verhalten ist die Tatsache, dass Chili nicht automatisiert die angegebenen Repositories ausliest. Dies geschiet lediglich, wenn ein unbedarfter Nutzer auf den Reiter “Repository” (“Archiv”) klickt (was wohl auch die Latenz dieses besagten Reiters erklärt). Man kann den Einlesevorgang aber auch mithilfe eines Rake-Tasks manuell anstoßen:

$ rake redmine:fetch_changesets

Dies sollte man entsprechend in einen Cron-Job oder Post-Receive-Hook des jeweiligen Versionskontrollsystems eintragen (ich bevorzuge ersteres, ist aber wohl Geschmackssache).

Naja, das ist aber noch nicht alles. Ruby habe ich für meinen Server selbst kompiliert, und zwar nach /usr/local und Cron tut standardmäßig böse Dinge mit Umgebungsvariablen, darunter auch PATH und RAILS_ENV. Außerdem muss beachtet werden, dass ChiliProject ja Bundler verwendet, und wenn man andere als die erforderlichen Gem-Versionen installiert hat, wird das zu einer Fehlermeldung seitens Bundler führen (zur Erinnerung: Ausgaben von Cron-Jobs werden als E-Mail an den ausführenden Nutzer verschickt). Fügt man all diese Probleme zusammen, entsteht ein Cron-Job wie (/CHILIPATH entsprechend ersetzen)

0 * * * * cd /CHILIPATH && PATH=/usr/local/bin:$PATH bundle exec rake redmine:fetch_changesets RAILS_ENV=production

Da das doch etwas unübersichtlich ist, habe ich ein kleines Skript geschrieben:

#!/bin/bash
# chili_fetch_changesets
cd /CHILIPATH
bundle exec rake redmine:fetch_changesets RAILS_ENV=production

das mit folgendem Cron-Job aufgerufen wird:

0 * * * * PATH=/usr/local/bin chili_fetch_changesets

Und schon werden die Commit-Nachrichten stündlich eingelesen. Von offizieller, d.h. der Chili-Project-Seite, gibt es diese Information ebenfalls.

Valete.