search

sogis / gretl

Contains custom gradle tasks to use in gradle builds. The custom tasks extend gradle for use as a sql-centric (geo)data etl. gretl = gradle etl
MIT License
4 stars 3 forks source link

Optimize build #138

Closed Saela closed 3 weeks ago

Saela commented 9 months ago

Analyze build logic To get more information about possible improvements we can run the github profiler on the build logic.

Possible Optimizations

edigonzales commented 8 months ago
  1. Soll der Dockerbuild weiterhin im gleichen Repo sein?
  2. Sollen sämtliche Integration-Tests auch vom Docker-Image durchlaufen werden?

Die Antworten geben Anhaltspunkte, ob man mehr oder weniger am Test-Code ändern muss. Heute wird mit Process p = Runtime.getRuntime().exec(command); https://github.com/sogis/gretl/blob/master/gretl/src/integrationTest/java/ch/so/agi/gretl/util/IntegrationTestUtil.java#L55 sowohl das Plugin als Jar wie auch das Dockerimage aus dem Integrationstest aufgerufen. Wenn man z.B. zum Schluss kommt, dass nur noch das Plugin als Jar voll geprüft wird, könnte man dieses Process-Gedöns mit Buildin-TestKit-Zeugs ersetzen.

Saela commented 7 months ago

@edigonzales Wie willst du hier vorgehen um die Fragen zu beantworten? Brauchst du da einen Sparring-Partner oder hast du bereits eine klare Idee in welche Richtung du willst?

edigonzales commented 7 months ago

Weil es ja im AP4 ist, können wir den Sparring-Partner-Zug fahren. Dann ist die Codebase etc. viel besser bekannt.

edigonzales commented 3 weeks ago

Ich würde die Dockertests immer noch hier laufen lassen und auch alles durchlaufen lassen. Zudem wir jetzt einiges investiert haben, damit die Dockertests wieder mit Docker laufen (siehe #135) .

Nachteile gibt es schon auch, aber die nehme ich momentan in Kauf: