GitHub Repository mit Travis CI Unterstützung

[Chris M.]

Gerade habe ich mal Travis CI auf GitHub für uns aktiviert.
Aktuell macht es nichts anderes als die *.js Dateien (ausgenommen: Dependencies) auf Zeilen zu checken, die mit einem Tabulator beginnen (-> Verstoß gegen https://github.com/CometVisu/CometVi...i/Coding-style)

Da es jetzt läuft, können wir natürlich dem ganzen mehr Aufgaben übertragen.

Vorschläge?

[peuter]

Ja ein syntax-checker wie jslint oder jshint. Und eventuell kann man den Coding-style mal für sowas hier definieren:
https://github.com/jscs-dev/node-jscs (hab ich allerdings gerade erst gefunden, kenne ich also nicht, aber sowas zu Formalisieren kann ja nicht schaden).

Ansonsten wäre es vielleicht eine Überlegung wert, das ganze Build System auf Grunt zu basieren, die Grunt tasks kann man dann vom Travis CI ausführen lassen. Da es ein Javascript Projekt ist, bietet sich Grunt doch irgendwie an. Und da gibts es viele Dinge die man nutzen könnte. Wie stehst Du dazu?

[Chris M.]

Ja ein syntax-checker wie jslint oder jshint. Und eventuell kann man den Coding-style mal für sowas hier definieren:
https://github.com/jscs-dev/node-jscs (hab ich allerdings gerade erst gefunden, kenne ich also nicht, aber sowas zu Formalisieren kann ja nicht schaden).

Ein Code Checker ist auch mein Wunsch. Wobei man die mit gewissen Abstand und Intelligenz betrachten muss, nicht alles was die sagen ist sinnvoll.

Ansonsten wäre es vielleicht eine Überlegung wert, das ganze Build System auf Grunt zu basieren, die Grunt tasks kann man dann vom Travis CI ausführen lassen. Da es ein Javascript Projekt ist, bietet sich Grunt doch irgendwie an. Und da gibts es viele Dinge die man nutzen könnte. Wie stehst Du dazu?

Ich kenne Grunt nicht. Und Travis eigentlich auch nicht wirklich... In der Travis Doku steht, dass die bei JavaScript Projekten Node.js verwenden/unterstützen, was ja irgendwie naheliegend ist...

Das aktuelle Build-System ist per Hand so hingetrimmt, dass irgendwie was sinnvolles herauskommt. Wenn wir da was besseres haben: gerne!

Sollte sich hier jemand auskennen: gerne melden (und machen )

[peuter]

Ja ich würde auch nicht einfach irgendeinen Code-Checker nehmen und den einfach so nutzen. Die Regeln nach denen man vorgeht müsste man schon genau definieren und hier ist meines Wissens nach jshint besser geeignet, weil konfigurierbarer als jslint.

Ich werde mich des Grunt-Themas mal annehmen und das Ganze in Travis einbinden. Mal sehen was es da alles so an nützlichen Tasks gibt, die für unsere Zwecke nützlich sind. Um das Ganze auch schön dokumentiert zu haben, gibts dafür ein enhancement-issue: https://github.com/CometVisu/CometVisu/issues/273

[peuter]

So Grundsystem steht:
https://github.com/CometVisu/CometVi...13bbd59f373fbb

Um Grunt zu nutzen muss man (in diesem Branch) folgendes tun:

npm install -g grunt-cli // braucht man nur sofern grunt noch nicht auf dem eigenen system installiert ist)
npm install // das lädt alle von cometvisu benötigten module

Danach kann man die verschiedenen Tasks ausprobieren:

grunt jshint // allgemeiner javascript syntaxchecker, läuft bisher mit default-settings und zeigt viele Fehler im Source-Code
grunt jscs // prüft ob der CometVisu coding-style eingehalten wurde
grunt usebanner // fügt automatisch einen aktuellen License-Header in die JS Dateien im lib/ und structure/pure Verzeichnis ein mit aktueller Version, aktuellem Jahr usw.
grunt manifest // generiert die cometvisu.appcache Datei für das Release
grunt requirejs // baut das release zusammen
grunt default // führt nacheinander jshint, jscs, usebanner, requirejs und manifest aus => macht also ein release, bricht aber zur Zeit ab weil jshint nicht durchläuft
grunt lint // führt jshint und jscs aus, soll später mal fürs CI sein, wenn jshint fehlerfrei durchläuft

Zum Jscs: bisher wird nur die Einrückung und der Zeilenumbruch gecheckt, max. Zeilenlänge von 80 hab ich erstmal auskommentiert, da sich da wohl selten dran gehalten wird im Source, weitere Dinge wäre natürlich möglich. Man kann dort z.B. presets laden und hat automatisch den z.B. den CodeStyle von jquery. Außerdem kann man das Ding so konfigurieren, dass die Sourcen selbsständig korrigiert werden. Das habe ich aber auch erstmal abgeschaltet, weil potentiell gefährlich. Bei den aktuellen Einstellungen kann da nicht viel passieren, damit hab ichs einmal durchlaufen lassen und er hat alles schon korrekt eingerückt (daher ist das Changeset in dem Commit auch so groß).

Zum Jshint: Hier müssten wir uns erstmal auf eine Syntax einigen, bzw. was geprüft werden soll und was nicht, dann kann man den einschalten.

Was noch dazukommt: ein Task, der aus dem fertigen Release eine zip bzw. tar.gz Datei macht

So das wärs fürs erste, hab ich was vergessen?

[peuter]

Compress Task ist jetzt auch drin, jshint hab ich erstmal rausgenommen. Jetzt kann man mit

grunt

einfach einen Build der CometVisu erstellen. Am Ende kommen dann eine tar.gz und eine zip Datei raus. Damit wären jetzt auch Nightly-Builds möglich.

[Chris M.]

Klingt interessant, muss ich ausprobieren.

Checkt Travis damit jetzt auch jeden Pull Request? D.h. bekommt man beim Review die Info das der Request zumindest Optisch und grob der Syntax nach i.O. ist?

[Chris M.]

Achtung, der Befehl Grunt zu installieren lautet korrekt:

npm install -g grunt-cli

Nachtrag:
Ein aktuelles [K]ubuntu braucht auch noch:

sudo ln -s /usr/bin/nodejs /usr/bin/node

[Chris M.]

So Grundsystem steht:

Konnte jetzt mal damit spielen:
1) es ist relativ langsam - evtl. weil es sehr gründlich ist?
2) sehr interessant - auch wenn ich bisher nicht mehr gemacht habe als einmal die o.e. Kommandos einzugeben

(daher ist das Changeset in dem Commit auch so groß).

Wenn der in den Haupt-Branch geht, wäre mir ganz lieb, wenn das auf verschiedene Pull-Requests aufgeteilt wäre. Einer um Grunt einzurichten und dann einer oder mehrere um den Code Grunt kompatibel zu machen.
So sollte es leichter sein zu sehen, ob wo und wieso etwas kaputt geht.

Zum Jshint: Hier müssten wir uns erstmal auf eine Syntax einigen, bzw. was geprüft werden soll und was nicht, dann kann man den einschalten.

Ja, aber da der Code bisher noch kaum durch einen JS-Linter gegangen ist, werden wir wohl nur Stück für Stück schärfer werden (können).
Müssen wir halt mit Verstand machen. Evtl. in einem neuen Thread, der sich nur um das Thema Lint/Hint kümmert. Da können wir dann genüsslich die einzelnen Regeln diskutieren.

So das wärs fürs erste, hab ich was vergessen?

Ich bin jetzt schon überfordert
Das beim reinen "grunt" gebaute Package ist noch nicht wirklich brauchbar, denke ich. Macht aber noch nichts. Das sollten wir schon noch fixen können.

peuter, wenn Du mit dem Thema zufrieden bist und es keinen Widerspruch gibt, wäre ich durchaus so mutig diese Änderungen in develop zu mergen (aber bitte einzeln, s.o.).
Dann könnte das noch bis zur 0.9.1 reifen.

Mir wäre es aber auch recht, wenn es erst nach der 0.9.1 kommt.

[Chris M.]

Ui, noch ein Beitrag von mir

So das wärs fürs erste, hab ich was vergessen?

Irgend ein JSDoc würde ich auch gerne mit einbinden. So dass wir die APIs automatisch in Doku wandeln lassen können (wenn die Kommentare dann passend nachgepflegt wurden...)

[peuter]

1) es ist relativ langsam - evtl. weil es sehr gründlich ist?

Bei einen Build-System ist die Performance doch relativ egal. Was genau ist Dir denn da zu langsam?

Das beim reinen "grunt" gebaute Package ist noch nicht wirklich brauchbar, denke ich. Macht aber noch nichts. Das sollten wir schon noch fixen können.

Da bräuchte ich auch genauere Infos. Ich habe mit dem was da am Ende rauskommt mal die Demo-Config aufgerufen und die wurde auch ohne Fehler geladen, viel mehr hab ich aber nicht getestet.

wenn Du mit dem Thema zufrieden bist und es keinen Widerspruch gibt, wäre ich durchaus so mutig diese Änderungen in develop zu mergen (aber bitte einzeln, s.o.).
Dann könnte das noch bis zur 0.9.1 reifen.

An sich hatte ich das auch erstmal getrennt. Das würde aber bedeuten, dass die Travis-Builds erstmal fehlschlagen, weil ja die Sourcen nicht korrekt "gestyled" sind. Und ja Travis wird auch pull request bauen/prüfen (hast Du ja so eingestellt ;-), daher hatte ich die Sourcen soweit angepasst dass der vom Travis ausgeführte "grunt jscs" fehlerfrei durchläuft. Außerdem hatte ich beim "builden" noch ein paar Fehler gefunden, die glaube ich durch das verschieben der Plugin-Dependencies in den 'dep' Unterordner entstanden sind.

Also soll ich das Build-System da "rausschälen" ohne die Änderungen am Source-Code und damit Travis erstmal "kaputt" machen? Ich würde da tendenziell lieber den PR mit dem Ist-Stand (+ zukünftige Verbesserungen) machen, aber dann halt nach 0.9.1.

Einen JSDoc Generator baue ich mal ein, für JSHint gibts da schon Möglichkeiten das zu checken (damit könnte man dann in Zukunft auch sicher stellen, dass es keine PR ohne vernünftige Dokumentation gibt), aber da in Sachen Syntax-Check gibts viele Möglichkeiten, die sollten wir dann wirklich mal in einem neuen Thread besprechen, wenn alles andere soweit fertig/gemerged ist.

[Chris M.]

Bei einen Build-System ist die Performance doch relativ egal. Was genau ist Dir denn da zu langsam?

Nun, meine Grep-Zeile war innerhalb weniger Sekunden durch, beim jscs muss man schon bewusst warten. Beim kompletten durchlauf erst recht.
Die Zeit für den Code-Checker so kurz zu haben, dass man gerne immer wieder schnell mal testet wäre schön - das ist aber keine harte Anforderung.
Die Zeit für einen kompletten Build ist IMHO bei ein paar Minuten nicht schlimm. Das macht man ja nur alle paar Monate zu einem neuen Release.

Da bräuchte ich auch genauere Infos. Ich habe mit dem was da am Ende rauskommt mal die Demo-Config aufgerufen und die wurde auch ohne Fehler geladen, viel mehr hab ich aber nicht getestet.

Ich hatte zu jeder JS Datei eine minimierte gesehen, aber nicht, dass alle in einer großen Datei zusammengefasst wurden. Evtl. hab ich's auch übersehen.
Aber da würde ich mir noch keinen Kopf machen. Wenn das Release naht, kann man hier an den Details feilen.

An sich hatte ich das auch erstmal getrennt. Das würde aber bedeuten, dass die Travis-Builds erstmal fehlschlagen, weil ja die Sourcen nicht korrekt "gestyled" sind.

Nur keine Angst vor Fail/Rot. Erzähle ich in der Arbeit auch immer den Kollegen, die ein Kirsch-Grün herbei diskutieren wollen. So sieht man, wo noch was gemacht werden muss. Und nur weil ein paar Ebenen weiter oben jemand nur auf die Farben und nicht auf den Inhalt schaut müssen wir ja nicht den gleichen Fehler machen.

Dennoch muss man natürlich aufpassen und die Grenze für ein Grün nicht unrealistisch hoch zu setzen.

Und ja Travis wird auch pull request bauen/prüfen (hast Du ja so eingestellt ;-), daher hatte ich die Sourcen soweit angepasst dass der vom Travis ausgeführte "grunt jscs" fehlerfrei durchläuft. Außerdem hatte ich beim "builden" noch ein paar Fehler gefunden, die glaube ich durch das verschieben der Plugin-Dependencies in den 'dep' Unterordner entstanden sind.

Das sollte natürlich auch alles in's Repository. Mein Wunsch wären halt zwei getrennte Pulls um sauber zu trennen. (Genau so, wie man Code-Formatierungs Pulls von inhaltlichen Pulls trennen sollte)

Also soll ich das Build-System da "rausschälen" ohne die Änderungen am Source-Code und damit Travis erstmal "kaputt" machen? Ich würde da tendenziell lieber den PR mit dem Ist-Stand (+ zukünftige Verbesserungen) machen, aber dann halt nach 0.9.1.

Da ich vermute, dass der Grunt Teil in getrennten Dateien liegt, sollte eine Aufteilung relativ leicht möglich sein, oder? (Das sind die Untiefen des Git,m die ich noch nicht sonderlich gemeistert habe...)

Einen JSDoc Generator baue ich mal ein, für JSHint gibts da schon Möglichkeiten das zu checken (damit könnte man dann in Zukunft auch sicher stellen, dass es keine PR ohne vernünftige Dokumentation gibt), aber da in Sachen Syntax-Check gibts viele Möglichkeiten, die sollten wir dann wirklich mal in einem neuen Thread besprechen, wenn alles andere soweit fertig/gemerged ist.

Die Strenge der Regeln würde ich im ersten Schritt eher liberal einstellen - eben weil der Code noch nicht so weit ist.

Und vor der 0.9.1 würde ich ungern im Code grundsätzlich rumrühren, die soll ja nur ein "Bugfix-Release" mit ein paar kleineren Verbesserungen sein.
Nach der 0.9.1 können wir dann die Regeln schärfer anziehen, den Code passend befähigen und auch gröber umbauen.

Um hier mal eine Daumenregel zu postulieren: Eine 0.9.1 möchte ich nur Releasen, wenn Travis einen grünen Haken setzt. (Ich denke damit hat man einen guten Anhaltspunkt für die Schärfe der Anforderungen)

[peuter]

So PR ist gestellt (ich habe einfach einen neuen Branch gemacht und die paar Dateien rüberkopiert und somit alle Git-Untiefen umschifft ;-). Die Momentanen Anforderungen sind ja sehr schwach, geht eigentlich nur um die 2-Leerzeichen-Einrückung und korrekten Linefeed. Lässt sich auch sehr einfach fixen, weil der den Code automatisch gerade ziehen kann. Der prüft übrigens Code-abhängig wieviele Einrückungen nötig sind (also innerhalb einer Funktion die mit 2-Leerzeichen eingerückt ist müssen es dann 4 sein). Daher ist das nicht weiter verwunderlich, dass das länger dauert als ein simples greppen nach einem Tab.

Wenn das also gemerged ist würde ich das einmal automatisch einrücken lassen und damit dann einen zweiten PR stellen, der dürfte dann auch Travis zufrieden stellen.

[Chris M.]

Hab's jetzt mal gemerged.

Was mir da noch aufgefallen ist (lässt sich aber wohl später noch leicht nachziehen):

• Gruntfile.js verweist paar mal auf peuter/CometVisu
• Der richtige Name ist "CometVisu" und nicht "Cometvisu"
• package.json hat Version "0.9.1-dev" hart eincodiert. Eigentlich haben wir eine "version" Datei um an einer Stelle die Version fest zu legen, nicht das die inkonsistent werden. Wie das optimaler gestaltet werden kann ist mir aktuell aber nicht klar.

[peuter]

Noch was zum Code-Checken während der Entwicklung. Ich nutze da zur Zeit eine Testversion von IntelliJ IDEA, die hat diverse Code-Checker eingebaut u.a. auch JSHint. Den kann man sich dann so einstellen wie man möchte (hier sieht man dann auch was es alles für Optionen gibt, sicherlich hilfreich bei der Wahl der richtigen Einstellungen für den späteren automatischen Code-Check.

Da meine Testversion demnächst abläuft würde ich gerne eine open-source Lizenz dafür beantragen. Der Hersteller Jetbrains bietet sowas an.
https://www.jetbrains.com/shop/eform...rce?product=II

Hättest Du ein Problem damit wenn ich das übers CometVisu-Projekt beantrage? Wenn ja, dann könnte ich auch direkt eine für Dich mit bestellen, wenn Du möchtest.