ATBUpdateTool/allgemein.txt

127 lines
4.2 KiB
Plaintext
Raw Normal View History

2023-07-16 18:31:15 +02:00
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