Some immediate advantages:
Centralized configuration of execution environment: Maven version, JDK, JVM options, ...
No more copying job configurations, which tends to leave obsolete options in some jobs (disabling animalsniffer even though it's not used anymore, allocating too much memory to the JVM, using an older version of Maven or of the JDK, ...)
Easier integration of each developper's git repository, and more importantly of development branches: the build configuration being centralized, one will only have to enable Jenkins for one's repository in order to enable CI.
Because of the above, we might be able to replace Travis with Jenkins, if we want to, leaving only a minimal configuration suitable for new contributors in Travis.
Easier setup of full integration tests in multiple environments (with ES2, ES5, ES6, mariadb, postgresql, jdk9, jdk11, ...). We used to set up one job per (branch, environment) pair. Now we can easily enable all those tests (or just some of them) for select branches, just by modifying some conditions inside the Jenkinsfile. For example we cold enable full integration tests by default for master and maintenance branches (5.11, 6.0, 6.1, ...).
We can build Hibernate Search once, then stash the built JARs to re-use them later in the pipeline in different environments. This is interesting for multiple reasons:
We can cut down the execution time of integration tests in other environments. For example we would only need to run mvn clean install -pl integrationtest/backend-elasticsearch to run ES ITs against ES2: no need to re-build the engine, or even the Elasticsearch backend, and no need to run unit tests again, since we already did in the main build.
We can finally correctly tests that our artifacts will work well in different JVMs. Currently when we test Hibernate Search with JDK11, we also build Hibernate Search with JDK11, which means we might miss some bugs related to running with JDK11 JARs built with JDK8. With the pipeline, we'll be able to build with JDK8, then test with JDK11, very simply and efficiently.
But mainly, what this brings is the ability to do more in the future:
Set up true continuous delivery:
Maybe: release by pushing to a release-<major>.<minor>.x branch. Not likely since we will want to customize the version number (Alpha or Beta or CR or Final). But maybe we could use appropriately named branches for that (release-<major>.<minor>.0.Alpha, release-<major>.<minor>.0.CR, ...).
More likely: publish a snapshot after each full build on the master/maintenance branches, instead of nightly.
This would allow a truly reproducible build, since the repository alone and a Jenkins instance would be enough to run the build: the Jenkinsfile would reference the exact containers needed to set up the correct environment for the build.
Perhaps more importantly, this would allow to maximize parallel execution of builds by setting up multiple executors per Jenkins slave. For that to happen, we will need other projects to also use containers, though.
We don't get to throttle builds (max 1 per hour, etc.) anymore, since that configuration would apply to the whole "Jenkins Multibranch pipeline job", which includes every single job instance for every single branch. => Actually that's not true, it seems we can dynamically generate this kind of setting within the JenkinsFile, and they will automatically be saved on a per-branch basis. Also, we can set the setting directly in the Jenkins UI for each branch.
We will lose some of the fine-grained rules of the Job Priorities plugin, since we will only have one job configuration per project. However, we will still be able to give higher priority to executions triggered by a user (such as releases).
I will set it up on our CI (it will only work for my development branch for now) and add more to these lists.