image build pipeline erstellen #161

soll enthalten:

format
lint
test
build
push to registry
dev: deploy to preview

Ziel ist ein einheitlicher Prozess in dev und prod.

Mögliche Lösung: Gitlab CI/CD (gitlab.com free tier oder self-hosted)

soll enthalten: - [ ] format - [ ] lint - [ ] test - [ ] build - [ ] push to registry - [ ] dev: deploy to preview Ziel ist ein einheitlicher Prozess in dev und prod. Mögliche Lösung: Gitlab CI/CD (gitlab.com free tier oder self-hosted)

Finde ich grundsätzlich gut, ich würde dafür aber gerne auf github actions setzen wofür wir ein Modell finden müssen, wie Issue Diskussionen weiterhin leicht zugänglich für Interessierte gestaltet werden können (d.h. nicht öffentlich, auf Deutsch).

Die Voraussetzung für größere Umformatierungen ist der Ausbau der tests. Ich hätte gerne 100% test coverage, weil es sehr zeitaufwändig ist alle Features des Kompass von Hand durchzutesten.

Finde ich grundsätzlich gut, ich würde dafür aber gerne auf github actions setzen wofür wir ein Modell finden müssen, wie Issue Diskussionen weiterhin leicht zugänglich für Interessierte gestaltet werden können (d.h. nicht öffentlich, auf Deutsch). Die Voraussetzung für größere Umformatierungen ist der Ausbau der tests. Ich hätte gerne 100% test coverage, weil es sehr zeitaufwändig ist alle Features des Kompass von Hand durchzutesten.

Warum github action statt gitlab? Ich finde das die gitlab pipelines sich wesentlich leichter bauen lassen, als die von github.

Bzgl. der partizipation lässt sich ja egal wo (gitlab (.com oder self hosted), github) ein private repo anlegen, in dem weiterhin andere Menschen auch Issue schreiben und lesen können.

Für die test ausbauten sollten wir ggf. noch ein weiteres Issue anlegen. Das scheint mir relativ viel arbeit zu sein.

Warum github action statt gitlab? Ich finde das die gitlab pipelines sich wesentlich leichter bauen lassen, als die von github. Bzgl. der partizipation lässt sich ja egal wo (gitlab (.com oder self hosted), github) ein private repo anlegen, in dem weiterhin andere Menschen auch Issue schreiben und lesen können. Für die test ausbauten sollten wir ggf. noch ein weiteres Issue anlegen. Das scheint mir relativ viel arbeit zu sein.

Warum github action statt gitlab? Ich finde das die gitlab pipelines sich wesentlich leichter bauen lassen, als die von github.

Weil ich github besser kenne als gitlab :) Und weil es dort sichtbarer ist.

Bzgl. der partizipation lässt sich ja egal wo (gitlab (.com oder self hosted), github) ein private repo anlegen, in dem weiterhin andere Menschen auch Issue schreiben und lesen können.

Pull requests müssten auf github (/gitlab) gemacht werden, das ist aber vermutlich okay. Das private repository müsste halt automatisch synchronisiert werden, aber auch das ließe sich wohl aufsetzen.

Für die test ausbauten sollten wir ggf. noch ein weiteres Issue anlegen. Das scheint mir relativ viel arbeit zu sein.

Gerne

> Warum github action statt gitlab? Ich finde das die gitlab pipelines sich wesentlich leichter bauen lassen, als die von github. Weil ich `github` besser kenne als `gitlab` :) Und weil es dort sichtbarer ist. > Bzgl. der partizipation lässt sich ja egal wo (gitlab (.com oder self hosted), github) ein private repo anlegen, in dem weiterhin andere Menschen auch Issue schreiben und lesen können. Pull requests müssten auf `github` (/`gitlab`) gemacht werden, das ist aber vermutlich okay. Das private repository müsste halt automatisch synchronisiert werden, aber auch das ließe sich wohl aufsetzen. > Für die test ausbauten sollten wir ggf. noch ein weiteres Issue anlegen. Das scheint mir relativ viel arbeit zu sein. Gerne

Weil ich github besser kenne als gitlab :) Und weil es dort sichtbarer ist.

Mir gehts da genau umgekehrt. Der sichtbarkeit stimme ich voll zu, auf github sind mehr Leute. Das ist aber egal wenn das repo eh private ist. Das lohnt sich also eigentlich nur, wenn die Entscheidung auf komplett open source fällt. Dann ist github sicherlich wesentlich größer als gitlab.

Das private repository müsste halt automatisch synchronisiert werden, aber auch das ließe sich wohl aufsetzen.

Was soll wohin synchronisiert werden?

> Weil ich github besser kenne als gitlab :) Und weil es dort sichtbarer ist. Mir gehts da genau umgekehrt. Der sichtbarkeit stimme ich voll zu, auf github sind mehr Leute. Das ist aber egal wenn das repo eh private ist. Das lohnt sich also eigentlich nur, wenn die Entscheidung auf komplett open source fällt. Dann ist github sicherlich wesentlich größer als gitlab. > Das private repository müsste halt automatisch synchronisiert werden, aber auch das ließe sich wohl aufsetzen. Was soll wohin synchronisiert werden?

Mir gehts da genau umgekehrt. Der sichtbarkeit stimme ich voll zu, auf github sind mehr Leute. Das ist aber egal wenn das repo eh private ist. Das lohnt sich also eigentlich nur, wenn die Entscheidung auf komplett open source fällt. Dann ist github sicherlich wesentlich größer als gitlab.

Mein Plan ist weiterhin es vollständig open source zu machen, hatte aber die letzten Monate nur wenig Zeit für Kompass. Ich glaube es fehlt eigentlich nur die JDAV logos zu entfernen.

Was soll wohin synchronisiert werden?

Das public repository soll das Original sein und das private repository nur eine regelmäßig geupdatete Kopie.

> Mir gehts da genau umgekehrt. Der sichtbarkeit stimme ich voll zu, auf github sind mehr Leute. Das ist aber egal wenn das repo eh private ist. Das lohnt sich also eigentlich nur, wenn die Entscheidung auf komplett open source fällt. Dann ist github sicherlich wesentlich größer als gitlab. Mein Plan ist weiterhin es vollständig open source zu machen, hatte aber die letzten Monate nur wenig Zeit für Kompass. Ich glaube es fehlt eigentlich nur die JDAV logos zu entfernen. > Was soll wohin synchronisiert werden? Das public repository soll das Original sein und das private repository nur eine regelmäßig geupdatete Kopie.

Labels Milestones

image build pipeline erstellen #161