Scripte unter Versionskontrolle

Hallo,

ich bin dabei etwas zu machen, um meine IPS-Scripte unter Versionskontrolle von git zu setzen, weil es ja schon praktisch sein kann, nachschauen zu können, was man so geändert hat.

An sich ja kein Problem. ich wollte dann auch gleich (wie bei Modulen) StyleCI benutzen, auch kein Problem … aber:

sowohl die Legacy- als auch die Web-Console speichern die Dateien mit Zeilenumbruch+Zeilenvorschub (CR+LF). StyleCI ändert das in Unix-Format (nur LF).

PHP ist das egal, der verarbeitet beides.

Das Problem ist nun, das nach jeder Änderung durch die Console immer die ganze Datei in git als geändert gilt, weil ja eben durch die Console immer jedes LF durch ein CR+LF ersetzte wird und durch StyleCI zurück.

Unschön.

Ich kenne keine Möglichkeit, der Console das Verhalten abzugewöhnen und habe auch keine Option gefunden, notfalls StyleCI dazu zu bringen, das zu unteröassen (wobei ich das Unix-Verhalten schon aus Gewohnheit lieber hätte).

Hat irgend jemand eine Idee, was man machen kann?

danke
demel

Soweit ich weiß kannst du aber bei Git im Repo dies Steuern was committed wird. Schau mal hier msysgit - How do I force git to use LF instead of CR+LF under windows? - Stack Overflow

paresy

hört sich perfekt an. probier’s nachher mal aus

halle paresy,

funktioniert soweit, ist aber etwas tricky, daher schreibe ich die Kommandos mal auf:

falls noch nicht erfolgt, Repository ganz normal clonen und dann …


git config core.autocrlf true

git rm --cached -r .
git diff --cached --name-only -z | xargs -0 git add
git commit -m "Fixed crlf issue"
git ls-files -z | xargs -0 rm
git checkout .

Quelle: dein link und hier.

Mein Fehler: ich habe nach dem ‚git config‘ die anderen Befehle nicht / nicht vollständig durchgeführt und dann hat das auf bereits vorhandenen Dateien keine Auswirkung - auch nicht bei neuen Änderungen :banghead:

Jetzt scheint es zu funktionieren.

Allerdings ist mir noch ein Problem aufgefallen: es wäre schon potentiell problematisch, wenn IPS-Script etc in einem öffentlichen git-Repository stehen würden - könnten ja durchaus persönliche Daten drin stehen.

Also entweder ein privates Repository auf GitHub, besser natürlich einen lokalen git-Server einrichten - habe ich sogar schon auf meine Synology laufen.

Dann ist StyleCI nicht mehr möglich; schade, zu mindestens bei größeren Script trägt das ja schon zu einer besseren Lesbarkeit bei.

Die Scripte enthalten ja u.U. soviel für IPS relevante Logik, das vermeintlich kleine Änderungen durchaus zu größeren Such-Aktionen führen können. Alleine die settings.json reicht (mir) nicht aus, ist auch, weil das ja auch die aktuellen Werte drin stehe, nicht ganz so einfach zu diffen - ich müsste bei jedem Objekt aus der Struktur „data“ die Felder „value“, „lastUpdate“, „lastChange“ ignorieren.

Nur damit ich nicht in etwas Arbeit hineinstecke, was bei euch ggfs. auf der Agenda ist: ihr plant nichts in dem Bereich?

danke einstweilen
demel

Man kann das lf Verhalten auch in .gitattributes steuern. Der folgende Eintrag erzwing das Unix Zeilenende bei jedem push/pull

#  perform LF normalization
* text=eol=lf

persönliche Angaben sollte man auch nicht an Github schicken, sondern entweder in einem include auslagern was durch die .gitignore nicht an Github übertragen wird oder man macht sich einen Branch für Github mit Dummy Daten und einen 2. Branch mit dem man arbeitet. Mit git merge lassen sich die Änderungen auch gut syncronisieren.

Aber so toll ist StyleCI nun auch wieder nicht, das man auf ein lokales Repository oder lokales Gitlab verzichten sollte.
Warum soll man sich einen fremden Style aufzwingen lassen, wenn man nicht dafür bezahlt wird. Wichtiger als die Form ist sowieso der Inhalt :slight_smile: - und ein effektiver Workflow.

Ich denke, die IPS Roadmap ist voll genug und Versionsverwaltung schon ganz gut durch Standardlösungen abgedeckt.

Tommi

das war auf keinen Fall so gemeint, das ich damit anregen wollte, das auf die IPS-Roadmap gesetzt wird, sondern rein die Frage, ob es da irgend eine Planung gibt.

demel

Es gibt da keinerlei Planung in diese Richtung.

paresy

Hallo,

ich habe an dem Thema weitergearbeitet und habe ein Modul geschrieben, was die IPS-Konfiguration unter git-Kontrolle sichert.

Das sind natürlich besonders die Script, aber auch alle IPS-Objekte sowie auch die installierten Module.
Der Webfront-Bereich wird noch nicht gesichert, wird aber noch dazu kommen.

Das Script kann ohne weiteres stündlich laufen, sodaß auch bei häufigen Änderungen die Übersicht erhalten bleibt, was geändert wurde.

Siehe IPSymconConfigVC

gruß
demel

Ein paar kleine Anmerkungen:

  • Du könntest die Module „weglassen“ und nur die URLs und CommitIDs von den installierten Modulen speichern. Unter der Prämisse, dass ein Entwickler seine Module nicht löscht, reicht das vollkommen aus um den Zustand wiederherzustellen.

  • Ich mag deine Idee, alles auf einzelne Dateien zu erlegen. Folgende Ideen hatte ich dazu mal:

  • Wenn du die settings.json zerlegst, anstatt die IPS_* Funktionen zu verwenden, könntest du diese einsparen und wirklich nur die Änderungen commiten (natürlich ohne Zeitstempel/Werte). Das würde weniger Rauschen auf dem Repo erzeugen. Natürlich mit dem Nachteil, dass die letzten Werte/Zeitstempel ggf. fehlen. Ein kleines Skript kann die settings.json aus den Einzeldateien wiederherstellen.
  • Man könnte die Baumstruktur als Dateinamen ablegen. Da Git „Renames“ erkennt, könnte dies klappen und es sehr leserlich werden.
  • Es gibt mehr als nur die Zeitstempel, die sich periodisch ändern können. z.B. können viele User Ihre Objekte periodisch sichtbar/unsichtbar machen. Ich habe noch keine gute Idee, aber evtl. müsste man eine „.ipsignore“ anbieten, wo genau diese Ausnahmen definiert werden können.
  • Wie schaut es mit der DB aus? Dort kannst du ganz entspannt alle Unterordner absichern, da wir ausschließlich abgeschlossene Datensätze abspeichern. Die Aggregation würde ich nicht sichern.

  • Da du erst ab der 5.0 dein Modul zur Verfügung stellst brauchst du fast alles aus der commons Datei unter libs nicht. Außerdem sind zumindest die Konstanten ebenfalls in deiner module.php drin :slight_smile:

Ansonsten super coole Idee!

paresy

Das habe ich auch: ich erstellen zu jedem Modul auf jeden Fall eine json-Datei, die die Git-URL, den gewählten Branch und den Zeitstempel (der letzten Änderung in einem Modul) enthält.

Die Zip-Datei ist ja optional und schon ein bisschen wie „Hosenträgen und Gürtel“, aber nicht ganz. Z.b. kann es ja sein, das es zu einem „komischen“ Verhalten kommt und man hat ein Modul aktualisiert. Mit dem Zip-FIle kann man dann notfalls mal eine ältere Version eines Moduls wieder installieren.
Grundsätzlich hast Du natürlich recht, man kann anhand der Commit-ID’s das auch wieder herstellen, aber da muss man schon genau verstehen, wie man das in git macht …

Ich hatte erst nur die settings.json als Basis genommen. Aber es gibt ein klitzekleines Problem: die settings.json wird ja (typischerweise) nur alle 10 Minuten geschrieben, d.h. ist nicht immer ganz aktuell. War vielleicht mehr ein akademisches Problem, aber bei meine Tests musste ich immer die 10 Minuten warten, bis ich prüfen konnte, ob die Änderungen geschrieben wurden und das war mir zu langweilig :smiley: und bin daher in die Richtung gegangen, die Objekte direkt auszulesen.
Dann ist man ja auch auf jeden Fall auf der sicheren Seite.

Grundsätzlich schreibe ich die Daten nur, wenn sich inhaltlich etwas geändert hat, damit der Zeitstempel der Datei gleich der letzten Änderung ist. Und damit ist auch nur das zu comitten.

Eine settings_nodata.json (also ohne Daten) hatte ich am Anfang auch erzeugt, aber den Code erstmal wieder tot gelegt.

Ja, eine interessante Idee. Meinst Du, die Struktur als Verzeichnis-Struktur darzustellen (also als Verzeichnisbaum analog zu dem IPS-Baum oder flach, d.h. flach der Dateinamen des Objekts einhält den Verzeichnisbaum?

Also so ist es im IPS


IP-Symcon (Kategorie)
+- Räume (Kategorie)
    +- Wohnzimmer (Kategorie)
        +- Dimmer (Gerät)
        +- Schalter (Gerät)

und die Sicherung dann so?


IP-Symcon (Verzeichnis)
+- Räume (Verzeichnis)
    +- Wohnzimmer (Verzeichnis)
        +- Dimmer (Datei)
        +- Schalter (Datei)

oder so?


IP-Symcon_Räume_Wohnzimmer_Dimmer (Datei)
IP-Symcon_Räume_Wohnzimmer_Schalter (Datei)

Ich würde auf jeden Fall sowohl die Objekts-ID und den Namen verwenden (per Hardlink).

Bei Namen habe ich nur das Problem, das man bestimmte Zeichen ausfiltern muss. SO müsste man den Backslash, der im IPS ja für die Verzeichnisstruktur verwendet wird ersetzen - weil das bei Windows ja der Verzeichnistrenner ist und ausserdem (bei Linux) ggfs. als Escape-Character interpretiert wird.

Mit dem Git-Rename muss ich noch etwas probieren, weil ich nicht genau weis, wie das funktioniert (ich stehe mit git etwas auf Kriegsfuß).

Ich lösche zZt neben den Zeitstempeln und der Variablenwerten auch die ChildrenIds. Über so eine .ignoriere-Liste denke ich mal nach …

ja, stimmt, bau ich ein.

Das mit dem Erstellen der ZIP-Datei ist ja kein Problem, allerdings habe ich ein kleines Problem, festzustellen, ob sich was geändert hat. Ein Vergleich von zwei zip-Archiven gibt ja immer ein Unterschied. Ich bin bei den Modulen daher dazu übergegangen, das ich vorher die Zeitstempel aller Dateien prüfen und mit den Zeitstempel des Archivs vergleiche und wenn sich da was unterscheidet, gehe ich von einer Änderung aus. Das ist natürlich nicht 100%-ig, weil man ja grundsätzlich auch Zeitstempel manipulieren kann, aber wenn das jemand macht wäre das ja schon schräg …

Ich wollte auch noch den webfront/user-Ordner optional sichern und der Vollständigkeit halber auch den skins-Ordner.
Wobei ich keine Skins habe und gar nicht weis, wie das aufgebaut ist. Ich meine gelesen zu haben ähnlich wie die modules Müsste ich mir mal ein Skin installieren …

Das stimmt, ich habe mit so ein Muster-Modul gemacht und das war für 4.4. Könnte ich mal aufräumen. Ja und mit doppelt in common.php und module.php ist natürlich auch richtig. Ist auch etwas historisch, weil ich mich erst später entschlossen hatte, eine common.php mit ein paar Standardfunktionen zu machen und bei allen meinen Modulen zu verwenden.

Was in IPS noch fehlt sind meines Wissens nach Konstanten für die Variablen- und Objekt-Typen, korrekt?

demel

Das ist kein Problem.
In der Repro URL beim Modul-Control funktionieren auch URLs mit CommitIDs.
Dann wird genau der gewünschte Commit geclont.
Michael

interessant, wie würde man die url’s dann aufbauen! ist das standardisierte (dann kann ich das ja nachlesen)?

demel

Ich habe mir einfach immer die Links auf der GitHub Website kopiert.
Ist bestimmt ein System hinter :wink:
Michael

jepp ich sehe es

https://github.com/<module>/commit/<commit-id>

und das kriege ich raus mit

git show

ja prima, dann baue ich das ein.

Nachtrag:

git rev-parse --verify HEAD

ist das Mittel der Wahl.

Vom Gefühl her präferiere ich ja die Verzeichnis Struktur. Dort kann man dann schöner navigieren. Das Filtern der Namen sollte kein Problem sein - der voll Name steht ja weiterhin drin. Die Dateinamen könnten ja Name.ObjektID.json sein.

Da die Daten für die Kategorien ja irgendwie auch gespeichert werden müssen, müsste dafür noch eine Datei her. Diese würde ich im Ordner ablegen in z.b. einer .irgendwas Datei.

Renames erkennt git automatisch.

Die ChildrenIDs sind in der settings.json gar nicht drin.

Du kannst übrigens auch IPS_GetSnapshot verwenden, wenn du nicht an die 10 Minuten gebunden sein willst. Dort sind jedoch ein paar Meta-Daten mehr drin, die du filtern willst.


timestamp
timezone
compatibility
isLocked bei Variablen
nextRun bei Ereignissen
crc bei Medien
size bei Medien
isAvailable bei Medien

paresy

Ich habe einiges geändert

  • Umstellung auf IPS_GetSnapshot()
  • Commit-ID der Module in den .json-Dateien gesichert, keine Zip-Archive mehr für Module
  • optional Zip-Archive für Verzeichnisse unterhalb von webfront/user
  • Sicherung der Informationen zu webfront/skins analog zu Modulen.
  • Sicherung von php.ini

noch offen:

  • Objekte unter Ihrem Namen speichern mit Darstellung der Verzeichnis-Struktur
  • optionale Sicherung der DB

demel

Was ist mit Modulen und Skins welche kein eigenes Repro haben und nur lokal existieren?
Werden die weiterhin gezippt?
Michael

war mir nicht bewusst, das es Module gibt, die nicht im Git abgelegt sind … aber klar, warum nicht.
hmm, für die könnte ich natürlich das zippen wieder reinnehmen, Skins dito.

Ich lerne dazu …

demel

Noch mehr Ideen :wink: Ich hatte überlegt, ob es theoretisch möglich wäre eine .gitmodules zu pflegen, die die Repos in „modules“ abbildet. Dadurch dürfte man beim Checkout des „Config“ Repositories recht einfach alle Module in der richtigen Version laden können.

paresy

hmm, kenne ich (noch) nicht. Fix mal das internet bemüht…
Das ist also eine Datei innerhalb des jeweiligen Moduls … oder hattest du an ein .gitmodule in dem übergeordneten module-Verzeichnis gedacht?

Die Informationen habe ich ja ( git-url, der branch und die commit-id ), insofern bestimmt machbar, aber mir ist der Nutzen noch nicht ganz klar.

demel