Ich suche nach einem plattformübergreifenden (Linux und OS X) Dateisystembeobachter, der die Platte nicht nach Änderungen abfragt (oder sehr effizient ist).
Dies wird das Kernstück eines Servers für die kontinuierliche Integration sein und Dinge wie das Kompilieren von LESS / SCSS, das Ausführen von JavaScript-Tests und das Ausführen von benutzerdefinierten Skripts behandeln. Ich möchte eine Liste von Dateien und Verzeichnissen angeben und Befehle ausführen, wenn sich eine Datei oder ein Ordner ändert.
Ich möchte etwas node.js, python, Shell-Skript oder Ruby-basiert.
Einige der Tools, die ich bisher angeschaut habe ...
doc.qt.nokia.com/latest/qfilesystemwatcher.html
buildr.apache.org/building.html#continuous-compilation
www.javascriptkata.com/2010/10/28/ready-js-prepare-your-javascript-for-production/
Alle Empfehlungen geschätzt.
Plattformübergreifend? Es ist sehr schwer. Ich kenne keine effektive plattformübergreifende Implementierung, aber vielleicht kann ich einen Ausgangspunkt vorschlagen.
Linux hat eine iNotify API , eine Kernel-Funktion, die Dateisysteme sofort überwacht warnt vor einer aufmerksamen Anwendung auf relevante Ereignisse. Das BSD / Mac-OS entspricht kqueue . Die beiden APIs scheinen sich sehr ähnlich zu sein.
Ich fand auf CPAN etwas Perl Wrapper für jeden von ihnen. Ich habe keine Erfahrung in Python, aber ich googelte einige Wrapper dieser APIs auch in Phyton. Sie haben " only ", um einen eigenen Wrapper um sie zu schreiben, um Ihre plattformübergreifende Bibliothek zu erhalten.
ist ein Shell-Skript ausreichend? sollte Cross-Plattform für * nix's sein
%Vor%Gute Frage und gut für Sie, wenn Sie Ihre Build- und Testverfahren automatisieren möchten. Kontinuierliche Integration ist der richtige Weg.
Wenn Sie git verwenden, gibt es keine Möglichkeit, einen Trigger in einem Git-Repository zu installieren? Sie könnten Ihren Trigger (der auf Ihrem lokalen Repository ausgeführt wird) dazu bringen, Ihre Änderungen zu übernehmen und dann einen Build / Testzyklus auf einem Build-Server zu aktivieren. Ein anderes Versionskontrollsystem verfügt möglicherweise über ähnliche Funktionen, wenn Sie kein git verwenden.
fswatch scheint der richtige Weg zu sein, besonders wenn Sie auch neue Dateien überwachen möchten.
Es ist Effizienz & amp; Die Stabilität hängt von der zugrunde liegenden OS-API ab. Hier ist das relevante Snippet aus der README des Projekts:
Die Einschränkungen von fswatch hängen weitgehend vom verwendeten Monitor ab:
- Der FSEvents-Monitor, der nur unter OS X verfügbar ist, kennt keine bekannten Einschränkungen und skaliert sehr gut mit der Anzahl der Dateien beobachtet.
- Der kqueue-Monitor, der auf jedem * BSD-System mit kqueue verfügbar ist, benötigt einen Dateideskriptor, der für jede überwachte Datei geöffnet wird. Daher skaliert dieser Monitor schlecht mit der Anzahl der Dateien beobachtet, und kann beginnen, sich zu benehmen, sobald der fswatch-Prozess läuft keine Dateideskriptoren mehr. In diesem Fall gibt fswatch einen Fehler aus Standardfehler für jede Datei, die nicht geöffnet werden kann.
- Der inotify-Monitor, der seit Kernel 2.6.13 unter Linux verfügbar ist, kann einen Warteschlangenüberlauf erleiden, wenn Ereignisse schneller generiert werden als sie sind aus der Warteschlange lesen. In jedem Fall ist die Anwendung garantiert erhalten eine Überlaufbenachrichtigung, die ordnungsgemäß bearbeitet werden kann genesen. fswatch löst derzeit eine Ausnahme aus, wenn eine Warteschlange überläuft tritt ein. Zukünftige Versionen werden den Überlauf behandeln, indem sie richtig ausgeben Benachrichtigungen.