Liferay dxp 7.2 jenkins CI/CD

Question

I am working on Liferay 7.2 deployment automation using Jenkins, We have Liferay workspace (Source code) in GitLab repository, my problem is i am not able to clone only single module (portlet) which is changed/modified and build it after push event in GitLab, instead whole workspace is getting cloned and build which consumes time to build all modules. I have implemented post commit hook in GitLab for any change in git repository. Please suggest how to implement this.

Answer 1

This is a really broad question and it will mainly depend on how your organization uses Jenkins.

With the push event you only know that it happens and Jenkins will load the code. It will not clone every time, unless you build a script that does that.

In any case, you will have a work environment created in Jenkins to represent that job, with an exclusive directory for it. To take advantage of modules already built, you will need to code your script for that.

Let's say, one idea is to take advantage of Gradle (BTW you can use the same programming language you use for Jenkins - Groovy). You can start by having a wrapper inside your workspace, saving the time to get it along all advantages a Gradle wrapper brings if living inside of your GitLab project.

With Gradle you can have building caches that really speed up you process, but it is kind of hard to make this happen inside a Jenkins job that has its own set of build artifacts for every job execution. You could however use Gradle to check or chose modules to build with a custom logic.

Let's say you started to tag modules with a file called version.propeties or a regular build.gradle with some indicator like "snapshot". This could be used by your Gradle building logic to select subprojects of your workspace (which is a Gradle project).

But in the end, you might end up noticing you have groups of modules that could be in other projects and some that are almost never updated, you might put them into their own workspace. There is no harm on doing that.

Another point is making sure you are using parallel building settings for Gradle and your hardware is up to the task. A Gradle daemon for your builds could help too.

There is an infinity set of factors that might help, but your environment is your main guide to tell you what you can do. An example of this is that your Jenkins sys admin could have already installed a global Gradle daemon, and a global Gradle environment where an artifact cache can live for your maven dependencies. They could also have installed a maven server that also acts as a cache for remote dependencies...

In the end, it is too broad to tell you any specific advise. But I will leave you with this: focus on Gradle more than Jenkins. Also, if you can speed up your dependency resolution and download time, that helps a lot in several projects.