Siema siema :)
Zacząłem się troche bawić z Jooqiem, fajna technologia, tylko mam jeden problem - mianowicie jak to pożenić z CI/CD i testami integracyjnymi np. w gitlabie?
Chodzi o sytuacje w której nie korzystam z in memory np. h2 tylko testcontainers.
@jarekr000000 wiem że Ty z Jooqa zdaje się korzystasz.
Nie rozumiem w czym jest problem.
Tu mam przykład niedawno robiony gdzie jest JOOQ, testy, CI (na github actions) - ale testy są na in mem database - zresztą wszystko działa na in mem h2 (bo to takie bieda demko).
https://github.com/neeffect/kotlin-stones/blob/master/stones-server/src/test/kotlin/pl/setblack/kstones/stones/StoneRepoTest.kt
Tylko niestety obsmarowane w mój dziwny framework więc Ci się raczej nie przyda.
EDIT: Możliwe, że najbardziej Ci będzie pomocny build do części server - tam są dwie rzeczy widoczne.
Liquibase inicjalizuje baze pod testy...
a jednocześnie na podstawie tej bazy jest generowany schemat do jooq.
https://github.com/neeffect/kotlin-stones/blob/master/stones-server/build.gradle.kts
Ok, tylko ja nie korzystam z bazy in memory tylko test-containers ;). Normalnie lokalnie idzie flyway, potem odpalam plugin jooq i mam kod. Zastanawiałem się nad wrzucaniem wygenerowanego kodu do gita, ale to może być dobre raczej tylko w jednoosobowych projektach.
A to nie jest tak, że po prostu CI odpala Ci builda, build generuje jooqowe klaski i potem lecą testy? Standardowa sytuacja raczej
Tak, ale AFAIK to jooq potrzebuje mieć aktywnego połączenia do bazy danych. Nie wygeneruje Ci z samych plików SQL, a żeby mieć Postgresowy TestContainer potrzebujesz mieć odpalone testy ;)
@scibi92 wersja enterprise jooq umie z sqli zrobić ;) No i możesz zawsze na janusza załadować sqla do h2 i potem odpalić jooq plugin żeby generował z tego h2 ;)
Nie wygeneruje Ci z samych plików SQL, a żeby mieć Postgresowy TestContainer potrzebujesz mieć odpalone testy.
To odpal sobie liquibase do pamięci w buildzie .
Poza tym strzelam, że da się jakąś gradlową magią przenieść kontener z bazą danych do fazy budowania projektu.
Możesz podbić tego iszju, bo widzę że kula się od trzech lat i nie może się dokulać do zrealizowania: https://github.com/jOOQ/jOOQ/issues/6551
Widzę też że ludzie próbują obejść w stylu generowanie klas gdzieś na boku, a nawet w osobnym kontenerze, albo wygenerowanie klas jooq z embedded DB przed odpaleniem testów
Na marginesie, TC możesz też odpalić niezależnie od testów np. zrobić Gradlowy task (jeśli używasz) i z niego odpalić TC, odpalić migrację liquibase, wygenerować kodzik i ubić TC
No ja znalazłem coś takiego:
import com.bmuschko.gradle.docker.tasks.container.DockerCreateContainer
import com.bmuschko.gradle.docker.tasks.container.DockerStartContainer
import com.bmuschko.gradle.docker.tasks.container.DockerStopContainer
import com.bmuschko.gradle.docker.tasks.container.extras.DockerWaitHealthyContainer
task createContainer(type: DockerCreateContainer) {
dependsOn pullImage
targetImageId { pullImage.getImageId() }
portBindings = ['8080:8080']
}
task startContainer(type: DockerStartContainer) {
dependsOn createContainer
targetContainerId { createContainer.getContainerId() }
}
task startAndWaitOnHealthyContainer(type: DockerWaitHealthyContainer) {
dependsOn startContainer
timeout = 60
targetContainerId { createContainer.getContainerId() }
}
task stopContainer(type: DockerStopContainer) {
target
I tak się żyje na tej wsi :D
Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.