127 lines
4.2 KiB
Plaintext
127 lines
4.2 KiB
Plaintext
|
0:
|
||
|
|
Zunaechst wir immer nachgesehen, ob das Repository bereits geklont wurde.
|
||
|
|
Wenn nein, dann wird geklont. Im Master-Branch befinden sich Dateinen, die
|
||
|
|
in allen anderen Branches gemeinsam genutzt werden. Das sollte wohl auf
|
||
|
|
jeden Fall fuer den DeviceController gelten.
|
||
|
|
1:
|
||
|
|
Anfrage bei ISMAS ob neue Daten da sind. Hier faengt die ganze Sache an.
|
||
|
|
Da man nicht weiss, on ISMAS ueberhaupt antworten wird braucht es einen
|
||
|
|
Timer. Man kann die Sache dann auch gleich mehrfach versuchen.
|
||
|
|
|
||
|
|
Die Anfrage geht also per Signal an den Apism-Client. Im Signal wird der
|
||
|
|
Zustand mitgegeben:
|
||
|
|
|
||
|
|
ISMAS_UPDATE_REQUEST_PENDING
|
||
|
|
|
||
|
|
und im Slot dann entsprechend uebernommen. Der Timer sollte nicht im Worker
|
||
|
|
stehen, sondern im Apism-Client. Der Worker sollte damit nicht belastet
|
||
|
|
sein. Der wird dann vom Apism-Client entsprechend benachrichtigt.
|
||
|
|
|
||
|
|
ISMAS_UPDATE_REQUEST_FAILURE
|
||
|
|
ISMAS_UPDATE_REQUEST_TIMEOUT
|
||
|
|
ISMAS_UPDATE_REQUEST_SUCCESS
|
||
|
|
|
||
|
|
Im 1./2.Fall wird dann ein Fehlerhandling durchgefuehrt. Insbesondere
|
||
|
|
wird Apism ueber den DB-Kanal darueber informiert (U0003). Am Ende wie
|
||
|
|
dann wie immer SendCmdVersion und beenden der Applikation.
|
||
|
|
|
||
|
|
Im Erfolgsfall muss in der Antwort der Branch enthalten sein, fuer den das
|
||
|
|
Update durchgefuhrt werden soll. Das ist auch bereits so (Location).
|
||
|
|
|
||
|
|
Ein Sonderfall waere der -m-Modus, da hier niemand auf der ISMAS-Seite
|
||
|
|
aktiv eingreift. Hier braucht es dann einen Ubergabeparameter an
|
||
|
|
ATBUpdateTool: --branch-name
|
||
|
|
|
||
|
|
Normalfall ist aber die Aktivierung via ISMAS. Dann muss der in der Antwort
|
||
|
|
enthaltene Branch zunaechst ausgecheckt werden.
|
||
|
|
2:
|
||
|
|
Dazu wird ein entsprechendes Signal an den GitClient gesandet.
|
||
|
|
|
||
|
|
GIT_CHECKOUT_BRANCH_REQUEST
|
||
|
|
|
||
|
|
Der GitClient sieht jetzt erstmal nach, ob es diesen Branch ueberhaupt
|
||
|
|
gibt.
|
||
|
|
|
||
|
|
Falls nein:
|
||
|
|
|
||
|
|
GIT_CHECKOUT_BRANCH_REQUEST_FAILURE
|
||
|
|
BRANCH_NOT_EXIST
|
||
|
|
|
||
|
|
Falls ja:
|
||
|
|
der GitClient versucht nun den Branch auszuchecken.
|
||
|
|
Geht das gut?
|
||
|
|
Falls nein:
|
||
|
|
|
||
|
|
GIT_CHECKOUT_BRANCH_REQUEST_FAILURE
|
||
|
|
BRANCH_CHECKOUT_ERROR
|
||
|
|
|
||
|
|
Falls ja:
|
||
|
|
GIT_CHECKOUT_BRANCH_REQUEST_SUCCESS
|
||
|
|
-> eventl. koennte man den Namen des Branches mitgeben
|
||
|
|
|
||
|
|
|
||
|
|
Signal an den Worker. Im entsprechenden Slot wird jetzt der eigentliche
|
||
|
|
UpdateProzess angeworfen.
|
||
|
|
3:
|
||
|
|
Mittels git fetch werden jetzt die Aenderungen ermittelt.
|
||
|
|
|
||
|
|
GIT_FETCH_UPDATES_REQUEST
|
||
|
|
|
||
|
|
GIT_FETCH_UPDATES_REQUEST_FAILURE
|
||
|
|
-> Worker informieren damit Fehlerbehandlung aktiviert wird
|
||
|
|
GIT_FETCH_UPDATES_REQUEST_SUCCESS
|
||
|
|
|
||
|
|
GIT_DIFF_UPDATES
|
||
|
|
|
||
|
|
Die Liste der geaenderten Dateien geht an den Worker. Der kann jetzt
|
||
|
|
noch Test machen, ob das Sinn macht. Evtl. eine Statusmeldung ausgeben
|
||
|
|
drueber was gleich passieren wird.
|
||
|
|
4:
|
||
|
|
Mittels git merge/pull werden nun die Dateien tatsaechlich im Branch
|
||
|
|
aktualisiert.
|
||
|
|
|
||
|
|
GIT_PULL_UPDATES_REQUEST
|
||
|
|
GIT_PULL_UPDATES_REQUEST_FAILURE
|
||
|
|
-> Worker informieren damit Fehlerbehandlung aktiviert wird
|
||
|
|
GIT_PULL_UPDATES_REQUEST_SUCCESS
|
||
|
|
-> Worker informieren
|
||
|
|
|
||
|
|
Sind die Daten vorhanden, dann werden sie mittels rsync ins Dateisystem
|
||
|
|
kopiert.
|
||
|
|
|
||
|
|
RSYNC_UPDATES
|
||
|
|
RSYNC_UPDATES_FAILURE
|
||
|
|
RSYNC_UPDATES_SUCCESS
|
||
|
|
|
||
|
|
Fuer jede kopierte Datei geht eine Nachricht raus ans ISMAS.
|
||
|
|
5:
|
||
|
|
Sind die Daten dann kopiert, so werden sie auf den DC kopiert (falls
|
||
|
|
notwendig): hier gehen dann wieder Nachrichten an ISMAS raus:
|
||
|
|
|
||
|
|
DC_UPDATE
|
||
|
|
DC_UPDATE_FAILURE
|
||
|
|
DC_UPDATE_SUCCESS
|
||
|
|
|
||
|
|
JSON_UPDATE
|
||
|
|
JSON_UPDATE_FAILURE
|
||
|
|
JSON_UPDATE_SUCCESS
|
||
|
|
|
||
|
|
Hier fuer jedes Json-File.
|
||
|
|
|
||
|
|
Schliesslich noch eine Zusammenfasung an ISMAS:
|
||
|
|
|
||
|
|
ISMAS_UPDATE_INFO_CONFIRM
|
||
|
|
ISMAS_UPDATE_INFO_CONFIRM_FAILURE
|
||
|
|
-> Worker informieren damit Fehlerbehandlung aktiviert wird
|
||
|
|
ISMAS_UPDATE_INFO_CONFIRM_SUCCESS
|
||
|
|
|
||
|
|
und schliesslich der abschliessende Status an ISMAS zurueckgemeldet:
|
||
|
|
|
||
|
|
ISMAS_CURRENT_PSA_STATUS_CONFIRM
|
||
|
|
ISMAS_CURRENT_PSA_STATUS_CONFIRM_FAILURE
|
||
|
|
ISMAS_CURRENT_PSA_STATUS_CONFIRM_SUCCESS
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|