Wir verwenden Jenkins und SBT-Plugging, um unsere Anwendung zu erstellen, zu testen und zu implementieren. Ich sehe überall, dass Leute "sauberen" Befehl vor "Test" oder "Stufe" verwenden, was zu sehr langen Kompilierzeiten führt.Ist es notwendig, SBT zu "reinigen", bevor "Bühne" für die Produktion gebaut wird?
Ist es notwendig, alles für jeden Build zu reinigen? Was ist das Risiko, den inkrementellen Compiler für Produktions-Builds zu verwenden?
Wenn sich das Build-Skript und/oder die Befehlszeile zu sbt nicht geändert haben, sollte es nicht notwendig sein, zu tun.
Ich habe Spark seit mehreren Jahren verwendet - und es ist eine der komplexesten sbt-Builds, die Sie finden können. Es funktioniert gut, um zu vermeiden, clean zu tun, solange der Build-Prozess selbst (wie in den Build-Artefakten Projekt/sbt und der sbt-Befehlszeile verkörpert) die gleichen wie vorherige Ausführungen sind.
Ich denke, es ist eine Frage des Geschmacks. Für kontinuierliche Integrations-Builds ist es in Ordnung, sich auf den inkrementellen Compiler zu verlassen; Wenn etwas fehlschlägt, kann ich ziemlich schnell nachforschen.
Aber wenn aus irgendeinem Grund der inkrementelle Compiler entscheidet, einige Änderungen zu ignorieren (und es ist mir bereits in der Entwicklung passiert), können Sie einige schwierige Fehler zu lösen.
Also, wenn Sie etwas wollen, das von einem neuen Code-Checkout reproduzierbar ist; einfach "sauber" vor allem anderen laufen.
In den meisten Fällen konfiguriere ich jenkins mit zwei Build-Tasks: Test-Builds, ausgelöst durch Code-Änderungen und Paketierungs-Builds für die Bereitstellung und periodisch ausgelöst (oder manuell in einigen Fällen mit automatischer Bereitstellung).