search

OperationPandoraTrigger / OPT-Server-Mod

Dieses Repo enthält alle Skripte aus dem OPT-Framework, die für den Betrieb der OPT genutzt werden.
GNU General Public License v3.0
5 stars 11 forks source link

Tools weiter zentralisieren #36

Closed senshi-x closed 5 years ago

senshi-x commented 5 years ago

Die Build-Skripte sollten weiter zentralisiert werden. Ultimatives Ziel ist es, einen "One-Click-Rebuild" zu ermöglichen.

Dafür müssen folgende Schritte erfolgen:

Wichtig dabei ist, dass die Mission an zwei Ziele verschoben wird: Die gebaute PBO muss AFAIK in den Arma 3\MPMissions-Ordner, damit der Server sie auch starten kann. Zusätzlich sollte bei jedem "Build Mission"-Schritt der Missionsordner selbst (ungepackt) in einen metadata-Pfad in den Documents gespeichert werden, damit man auch per Editor direkt Zugriff darauf hat.

In der Konfig müssen also folgende Pfade angegeben werden:

All diese Tools sollten aus allen Repos gleichzeitig zu erreichen sein. Insofern müssen sie entweder überall identisch gespiegelt werden, oder wir richten vielleicht doch einfachheitshalber ein eigenes Tools-Repo ein, um dieses Hickhack zu vermeiden.

Bitte diskutieren.

Frozen-byte commented 5 years ago

Dann wohl doch ein neues Repo und mit Submodul arbeiten. Alternative wäre die verschiedenen Repos zusammen zu legen und mit einem Monorepo zu arbeiten.

Krzmbrzl commented 5 years ago

Ich denke ein zentrales Repo für die Skripte ist am Besten. Dann kann zB auch die armake Version ganz einfach geupdatet werden

formtapez commented 5 years ago

Eigenes Tools Repo wäre gut. Aber dann brauchen wir keine Submodules wie @Frozen-byte sagte.

Was aber unschön dabei wird: Es müssen dann im Metadata die Pfade wohin man die Repos ausgecheckt hat angegeben werden. Wenn man mal eben zum Testen woandershin auscheckt, muss man wieder die Pfade anpassen :(

formtapez commented 5 years ago

Ein Monorepo hätte aber auch ein paar schicke Vorteile:

  1. Scripte finden stets die richtigen Locations für Client, Server, Mission. Es brauchen keine Pfade konfiguriert zu werden.
  2. Man hat stets ein passiges Gesamtpaket wenn man sich das Repo clont.
  3. Issues, Canban, Projekte, Wiki usw. sind zentral verwaltbar und man braucht sich nicht erinnern in welchem Repo das nun liegt.
  4. Versionsbezeichnungen in Client-, Server- und Missions- PBO-Dateinamen wären immer identisch.
Krzmbrzl commented 5 years ago

Da es sich aber um getrennte Projekte handelt (Mission, Client- und Servermod) halte ich ein Monorepo für unpassend. Das wird dann nur unnötig groß...

Wie geht das ohne Submodule @formtapez? :thinking:

formtapez commented 5 years ago

Naja, wenn ein Scriptpaket "alles" bauen soll, dann wird es ja zentral gestartet und muss wissen wo die einzelnen Repos liegen. Die Notwendigkeit, das als Submodul in den einzelnen Repos einzubinden, ist damit nicht mehr gegeben.

senshi-x commented 5 years ago

Einmal ein paar Pfade zu konfigurieren stört gar nicht. Dann bleibt es auch mit jedem Workflow kompatibel. :)

Bin zwar auch kein großer Fan von Monster-Repos, aber würde auch die Multi-PRs obsolet machen (z.B. Beam, welches einen PR für Client- und Servermod braucht). Da sehe ich aber das Multi-PR trotzdem noch als kleineres Übel.