Hier einmal der Prozess, wie Shipcloud sich verhält und was wo zu finden ist:

Die Pipeline läuft an, wenn

1) Ein neues Release gebaut wird (per Definition setzen eines Tags, der (aktuell) mit 1 beginnt)
2) Ein push auf den develop Branch gemacht wird

In beiden Fällen ist der Ablauf der gleiche:
- Anpassung der Version in den Dateien metadata, composer und docs/source/conf.py
- Dokumentation wird gebaut
- Paket wird gebaut (NPM, Datenzusammenfassung + Zippen)
- Übertragung der Daten zu download.y-square.de (bestehende gleiche Versionen werden dabei überschieben, wir bekommen also nicht bei jedem develop push ein neues Verzeichnis auf dem Server. Solange die VERSION gleich bleibt wird die alte durch die neue Version überschrieben)
  - /packages/ys_shipcloud/YS-Shipcloud-$VERSION.tgz
  - /docs/ys_shipcloud/$VERSION/html

  $VERSION ergibt sich wiefolgt:
  - Push auf development: Die letzte Release-Version wird genommen, der mittlere Digit um eins erhöht und -dev angehangen. Also Stable 1.2.0 -> 1.3.0-dev (weil weiter entwickelt als 1.2.0 aber noch nicht released)
  - Release gebaut: Beim bauen eines Release über git-flow geben wir als Tag die neue Versionsnummer mit, also z.B. 1.3.0. Diese wird dann verwendet.
  - Vielleicht für später, noch nicht implementiert: Hotfixes sollten die letzte Zahl der Version ändern. Das ist der Fall, wenn man mal für einen Kunden oder eine ganze Gruppe schnell man ein Update zur Verfügung stellen muss/will. Oft passiert das auf älteren Versionen, die noch draussen in der Wildnis von uns supported werden (müssen). Das würde ich mir aber dann überlegen, wenn es soweit ist (hotfix branch, extra tagging etc...)

Das heißt:@Daniela: Wann immer Du deine Änderungen auf develop pushst wird die Doku neu gebaut
@all: Jeder develop push lässt die Pipeline laufen. Aktuell dauert das zwischen 45s und 1min. Denkt an unser Usage-Kontingent. Pushen also frei nach meiner Geschichtslehrerin: So wenig wie möglich und so viel wie nötig :-)