GitHub Repo und Translator

[Flemmbrav]

Hallo zusammen,

derzeit bauen wir relativ viel an unserem Git herum, in Richtung hilfreicher Skripte.
Die Anbindung des Paksets an den Translator ist eine der eher aufwändigen Aufgaben, die wir derzeit manuell tätigen.
Auch ist es nicht gerade fördernd, dass nur eine Person neue Objekte in der Translator laden kann.

Von daher die Idee, ob nicht ein Skript automatisch den Inhalt des Gits in den Translator laden kann?
GitHub selbst bietet auch die Möglichkeit an, bei jedem Commit ein(oder mehrer) Ubuntu(?) Programme laufen zu lassen, so dass der Translator eigentlich gar nicht auf das Git schauen müsste.


Meint ihr, das hat eine Chance?
Ist es realistisch, dass ich mir vorstelle, dass ich im Prinzip einfach GitHub sage, es soll nach dem Commit das Git zip-pen, und dann an den Translator schicken?

[makie]

Auch ist es nicht gerade fördernd, dass nur eine Person neue Objekte in der Translator laden kann.

Derzeit können Leartin und Flemmbrav hochladen.
Bis zu 6 Namen können eingetragen werden.

Von daher die Idee, ob nicht ein Skript automatisch den Inhalt des Gits in den Translator laden kann?

Grundsätzlich lässt sich das ebenso automatisieren wie das herunterladen der Texte.

Siehe -> get_lang_files.sh

Der Objekt Import ist im Bereich zu dem man sich Anmelden muss.
Das Script muss also User und Passwort wissen und sich ebenfalls anmelden.
Und man muss noch das Problem knacken wie läd ein Script die zip Datei hoch. Analog zur Web Seite.

[Andarix]

...
Und man muss noch das Problem knacken wie läd ein Script die zip Datei hoch. Analog zur Web Seite.

An sich ist das kein Problem.

Man baucht dazu nur einen gemeinsamen ftp-Account.

Der der hochladen möchte überträgt zum ftp-Account. Und der wo es hin soll holt es von da ab.
Man braucht halt nur eine Instanz, die erst das Script zum hochladen beim Sender auf ruft und dann nach einer Karenzzeit ( Uploadzeit + Puffer ) das Script beim Empfänger aufruft der es abholt.


Einziges Problem dabei ist die Absicherung gegen Angriffe, wenn die entsprechenden Scripte öffentlich einsehbar sind. Selbst wenn man die Zugangsdaten nicht mit rein schreibt, eröffnet sowas dann Anreize dort Angriffe zu starten, weil das die Möglichkeit eröffnet Zugriff auf den empfangenden Server zu bekommen.

....
Ist es realistisch, dass ich mir vorstelle, dass ich im Prinzip einfach GitHub sage, es soll nach dem Commit das Git zip-pen, und dann an den Translator schicken?

Nun ja, das ist Ansichtssache.

Wenn sich eine Datei mit paar kbyte ändert, dann immer das gesamte Repo packen ( mehrere 100 Mbyte ) und hochladen treibt den Traffic nach oben.
Da stellt sich dann die Frage ob so was Sinnvoll ist oder nicht. Nur weil etwas geht/machbar ist muss es nicht immer auch Sinnvoll sein.
Da gehen dann die Ansichten aber auch auseinander, denn der der es bezahlen muss denkt da anders als der der es umsonst bekommt.

[Flemmbrav]

Das ist sehr schade.
Ich melde mich wieder, wenn ich einen Weg finde.

[Leartin]

Wenn das Skript nur lokal auf meinem oder Flemms Rechner wäre, müsste man sich keine Gedanken wegen der Logindaten machen.
Mit hashes könnte man verhindern, dass jeweils das gesamte Set hochgeladen wird. Werden ja theoretisch auch schon beim paken verwendet.
Es dürfte reichen, wenn das Skript einmal die Woche läuft und nicht bei jedem Upload, oft wird ja doch was hochgeladen und kurz darauf das gleiche Objekt nochmal abgeändert. Und wenn gar nichts hochgeladen wurde, dann ist alles schon gehasht und das Skript endet ohne upload.

[Flemmbrav]

Alternativ benötigt man ja eh die Sourcen, und nicht die .pak Dateien.
Man könnte auch eine Git-Client nutzen, und dann wirklich nur die Changes übernehmen.

[prissi]

Mit dem gleichen Skript, dass das Pakset nightly nach den Änderungen baut, könntest du auch die geänderte dat rasufischen per git und die an dern Translator schicken. Ist aber eher schwieriger, als das Nightly zu bauen ...

Aber das Loginproblem kann man so lösen, denn man kann auf github "secrets" (geheime Umgebungsvariablen) setzen, die dann Passwörter etc. beinhalten können.