All upstream Jenkins jobs related to Mandrel are encoded in Jenkins DSL now

[Karm]

How one works with it:

1. Do a change in jenkins/*, have it merged.
2. Click build now on this job https://ci.modcluster.io/view/Mandrel/job/dsl-mandrel-jobs/
3. It fails the first time, because your changes are pending script approval; Open https://ci.modcluster.io/scriptApproval/ and approve
4. Run step 2. again and it is all regenerated as one would expect.

Ad step 3.: I am investigating if it is really necessary and what additional security it actually brings.

Readme/docs on the syntax: https://ci.modcluster.io//plugin/job-dsl/api-viewer/index.html

[Karm]

@zakkak Nudge nudge

[zakkak]

@Karm this is a great improvement but the fact that you have to replicate so many things seems wrong to me.

E.g., why can't we have a single mandrel_linux_build.groovy that will be able to build 20.1, 20.2, 20.3, and master using a matrix of configurations?

I also don't understand the purpose of build.sh and buildLabsJDK.sh since they are not used in any job and they don't seem generic.

Additionally (Jenkins DSL newbie question), is there any way to have some form of library that you can then reuse across the different jobs?

[Karm]

@zakkak THX for the feedback. I will comment & fix step by step. First: buildLabsJDK.sh and build.sh are there by mistake. I used them locally for myself, never intended to push them 🤦 Lemme fix that...

[Karm]

@zakkak /me testing new updates

E.g., why can't we have a single mandrel_linux_build.groovy that will be able to build 20.1, 20.2, 20.3, and master using a matrix of configurations?

It can be done as a matrix job. But then it would always trigger a publisher that would run tests even for versions that weren't built... Maybe I am lacking Jenkins DSL-fu on this one. I managed to get rid of the duplicated shell by stuffing it into a separate file and I will be trimming that file further down by delegating tasks to build.java.

I also don't understand the purpose of build.sh and buildLabsJDK.sh since they are not used in any job and they don't seem generic.

A stupid mistake of mine. These files should not have been committed at all. They are gone now.

Additionally (Jenkins DSL newbie question), is there any way to have some form of library that you can then reuse across the different jobs?

I am no Jenkins DSL pro either. I used it once before and to my best knowledge, that would have to be converted into Jenkins Pipelines syntax to re-use components like libraries. I wouldn't bother with that at this point.

My overall intention for this PR is:

• to get rid of clicking in the GUI and to enable us to e.g. bump a Quarkus version or to add/remove Mandrel version with a single text commit
• allow me to easily create a similar job(s) on other Jenkins instances as/if needed

[Karm]

@zakkak It should look better now.

BTW: To test it, I had to leave

        choiceParam(
                'PACKAGING_REPOSITORY',
                [
                        'https://github.com/Karm/mandrel-packaging.git',

there and port scripts to 20.1 branch: #82

I will swap it to https://github.com/graalvm/mandrel-packaging and edit the branches (jenkins -> master and 20.1-jenkins to 20.1) before merging.

[zakkak]

LGTM!

I managed to get rid of the duplicated shell by stuffing it into a separate file and I will be trimming that file further down by delegating tasks to build.java.

The only "missing" thing I see is the trimming of the build scripts by delegating tasks to build.java, but I don't think this is a strong requirement.