Nix für Travis CI build verwenden

[sternenseemann]

Das geht dann alles viel schneller, weil die Packages von den binary caches heruntergeladen werden können!

[timjb]

Die Frage ist ja auch, wie schnell Nix installiert werden kann.

Eine Alternative wäre vielleicht, auf Circle.CI umzusteigen. Hier wird behauptet, die würden Dependencies cachen, um Builds zu beschleunigen.

Nachdem jetzt cabal exec benötigt wird, um die CSS-Dateien zu bauen und dazu erstmal bei Travis die neue Version von Cabal installiert werden muss, liegt die Dauer eines Build bei ~20min.

[sternenseemann]

nix installiert sich recht flott, weil es ein binary install gibt.

curl https://nixos.org/nix/install | sh

Das würde ich zuerst einmal antesten

[timjb]

Ich habe mal Circle.CI getestet. Leider gibt es beim Kompilieren von pandoc einen Fehler, den auch Google nicht kennt. Möglicherweise liegt das daran, dass Circle.CI nur GHC 7.8.3 kennt.

[sternenseemann]

@aszlig könnten wir über die hydra auf ein branch pushen lassen?

[aszlig]

Theoretisch schon, allerdings waer das IMHO ein wenig zu noisy, wenn dann bei jedem rebuild wieder zeug in die gh-pages branch gepushed wird. Ich koennte jedoch die generierte site auch direkt ausliefern lassen.

[timjb]

Ich finde das nicht problematisch, wenn jeder Rebuild zu einem Commit und Push führt. Ich finde den gh-pages-Ansatz im Gegenteil praktisch:

• Man kann in der Zeit zurückreisen, und sich anschauen, wie die Webseite zu einem gewissen Zeitpunkt ausgesehen hat.
• Man kann nachvollziehen, zu welchen Änderungen eine Änderung in den Source-Dateien geführt hat.
• Das hilft insbesondere bei eventuellem Debugging von Fehler.

Am wichtigsten finde ich aber:

Es gibt keinen Webserver, um den sich einer von uns kümmern muss. Und wenn es Probleme gibt, dann kann jeder von uns sie beheben.

[sternenseemann]

@aszlig meint glaube ich eher, dass hydra builds nicht nach commit gehen?

[timjb]

Committed werden sollte natürlich immer nur dann, wenn sich etwas am Output geändert hat. (Mit Git kann man leere Commits sowieso nur mit einem extra Flag erzeugen.)

[aszlig]

@lukasepple: Das mit den Commits an sich ist kein Problem.

Was ich allerdings doof finde ist das Duplizieren davon, die Unterschiede zwischen den Outputs sieht man so oder so an den Hydra-builds. Debugging ist hier ebenfalls kein Argument, weil jeder build zu 100% remote als auch lokal reproduzierbar ist (einfach realize der .drv und man hat dasselbe Ergebnis, selbst wenn der Store-Path remote nicht mehr vorhanden ist).

Was Hosting betrifft isses natuerlich einfacher wenn die Leute selber noch rumgschichteln koennen, das stimmt. Wird allerdings interessant bei der Merge-Strategie (ours? theirs? force-push?) - idealerweise waere diese dann natuerlich force-push oder update-ref um auch Side-Effects komplett zu eliminieren.

[timjb]

Bei jedem Build sollte der aktuelle Stand von gh-pages gepullt werden und dann die Änderungen, die sich aus den Änderungen an den Source-Dateien ergeben, committed werden. In der kurzen Zeit zwischen dem Pull und dem Commit und Push sollte es normalerweise keine anderen Commits geben, sodass eine Merge-Strategie überflüssig ist.

Natürlich sollte niemand am gh-pages manuelle Änderungen vornehmen.

[Profpatsch]

Die Hydra braucht ca. 300 Sekunden um Änderungen zu erkennen und neu zu bauen. Können wir das Ergebnis nicht daran binden? Siehe https://headcounter.org/hydra/jobset/curryclub/website#tabs-evaluations

[aszlig]

@Profpatsch: Man koennte statt den 300 Sekunden auch 'nen GitHub-Hook verwenden, dann isses bei jedem Commit.

[sternenseemann]

Die Hydra braucht ca. 300 Sekunden um Änderungen zu erkennen und neu zu bauen. Können wir das Ergebnis nicht daran binden?

das Diskutieren wir ja gerade :p

[Profpatsch]

Also zwei Lösungen, eine temporäre und eine coole:

1. Einen Eval-Hook für Hydra schreiben, der hier den Output des site-Jobs nach gh-pages pusht.
2. Eine VM für die Seite einrichten und die Domain umbiegen. Die VM dann immer updaten, wenn die Hydra einen Job fertig hat.

[timjb]

Ich habe jetzt den Build-Service von TravisCI auf CircleCI umgestellt und bin begeistert! Dieser CI-Service cacht mit Cabal installierte Dependencies.

Ergebnis: Wenn man jetzt zum master-Branch pusht dauert es nur noch ca. eine Minute, bis die statischen Dateien im gh-pages-Branch aktualisiert sind.

Die Lösung verwendet jetzt zwar kein Nix, aber das Problem war ja auch nicht "wir sind uncool weil wir noch kein Nix verwenden", sondern "die Builds dauern zu lange".

[Profpatsch]

Das ist gut.