CODEWITHSUNDEEP
javajenkinscontinuous-integrationjooq
pafede2
pafede2

Reputation: 1704

jOOQ continuous integration approaches

I've set a Java project using jOOQ. Currently we are about to create a CI pipeline on Jenkins.

Ideally, we wouldn't like commit the generated code on the repo but to generate it on the building process. However jOOQ requires to connect to the database in order to generate the code.

The first approach would be to allow Jenkins to connect to the database. In case we are forbidden to access to the DB from Jenkins, which are the approaches we should consider?

Any comments or hint is welcomed and much appreciated.

Upvotes: 4

Views: 1119

Answers (1)

Lukas Eder
Lukas Eder

Reputation: 220952

Why not commit generated code to a repository?

There are pros and cons to each approach as you have noticed, but in general, committing the generated code has more pros. Look at that code like any other library with its own release cycle and versioning. You might have such libraries, and you might call them libraryAbc-1.3.17.jar and you don't have any issues committing that jar file to the repository, right? Especially, when it's a third party dependency.

Here's an interesting article illustrating the above with more details:

And a recent discussion on the jOOQ user group:

Options for regenerating code without a database connection

Notice how that discussion references an option for re-generating the code from a meta model that is not the database, e.g.:

All of these have the advantage of taking a meta model from the file system at the price that they don't support all the vendor-specific functionality that would be supported if connecting directly to the database.

But why not use testcontainers with your actual database product? An example can be seen here.

Upvotes: 7

Related Questions