Jooq + CI/CD

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