Service Updates for Liferay Cloud Version 3 and 4

The services update to 2020.24.1 includes updates to Backup, Database, and CI services.

Version Compatibility between 3 and 4

All of the Version 4 Liferay Cloud service images are compatible with the older workspace structure except for Liferay. Due to the multi-stage build process used by the Liferay version 4 image, it is not compatible with the old workspace.

In order to use the Liferay service version 4, you need to update your project workspace. For details on updating your project please see this guide. Also, If you want to find out more about the new features that are offered through the services please go here.

The following environment variables need to be set to make the version 4 images work in the old workspace for Backup and CI services.

Backup

LCP_BACKUP_VOLUME_UID: "999"
LCP_BACKUP_VOLUME_GID: "999"

CI

LCP_CI_SCM_JENKINSFILE_HOOKS_DIR: "lcp/ci/"
LCP_CI_SCM_JENKINSFILE_PATH: "Jenkinsfile"
LCP_CI_USE_DEFAULT_JENKINSFILE: "false"

Setting the above environment variables is only necessary if Backup and CI services 4.0.0+ are going to be used for a project that has not completed the workspace upgrade.

Choose the Right liferay/dxp Docker image

The Version 4 Liferay service allows the end user to specify the fix pack level through the liferay/dxp docker images.

When choosing an image please use a fully qualified version with a timestamp.

Please use this tag:

liferay/dxp:7.2.10-sp2-202005120922

Instead of this one

liferay/dxp:7.2.10-sp2

The docker tags without the timestamp are rolling tags that update frequently. However, due to aggressive image caching, you may not receive the latest version of that tag when specifying it as your base liferay image. In order to avoid caching issues, always use the tag with a timestamp suffix.

The liferay/dxp image tag is specified through the gradle.properties file in your /liferay folder.

The minimum compatible liferay/dxp version for liferaycloud/liferay-dxp:7.2-4.0.0+ is sp1 (ga1 or fp1 will not successfully establish a cluster).

CI Service Default Jenkinsfile

In the Version 3 image of CI, the built-in Jenkinsfile (starting with version 3.2.0) is not enabled by default, and versions below 3.2.0 are only using the Jenkinsfile located in the project root. However, when updating to CI service 4.0.0+, the built-in Jenkinsfile is enabled by default. If you want more information about the built-in Jenkinsfile please go here. 

Please consider the appropriate CI pipeline settings for your project when updating to CI service 4.0.0+.

Known Issue with 4.0.0 and 4.0.1 Liferay Service: 

The upgrade workspace script adds Kubernetes secrets to your DXP Cloud project to store the jdbc connection details. If this creation process is not successful, and the Liferay service version 4.0.0 or 4.0.1 is deployed, then the liferay service will not start due to a failure to set the required jdbc environment variables. The cause of the startup failure is known and a fix will be released in version 4.0.2.

The current workaround is to add the following environment variable to your Liferay service

LCP_LIFERAY_PORTAL_PROPERTIES_FILES: "/opt/liferay/portal-all.properties"

Bitbucket Integration Username and App Password

As of CI service version 3.2.0, the Liferay Cloud CI can integrate with GitHub, GitLab, and BitBucket. The default git provider is GitHub, but the others can be specified with the following environment variable:

LCP_CI_SCM_PROVIDER: "github"|"gitlab"|"bitbucket"

 In order to integrate with a bitbucket, the user needs to create an App Password. This password is associated with a specific bitbucket user. This creates a potential problem when the project is using an App Password that is associated with a User that does not have the same name as the project Workspace. To solve this problem you need to specify a new environment variable for the CI service LCP_CI_SCM_USERNAME.

The following are the required environment variables to integrate with bitbucket using a Workspace that differs from the App Password User.

LCP_CI_SCM_PROVIDER: "bitbucket"
LCP_CI_SCM_USERNAME: "User who created the App Password"
LCP_CI_SCM_TOKEN: "App Password"
LCP_CI_SCM_REPOSITORY_OWNER: "Workspace Id of the project"

If your project is using github or gitlab then the LCP_CI_SCM_USERNAME environment variable is not necessary

Version 4 DXP Stack 2020.24.1 

 Version 4 Update Instructions

Only Applicable to Version 4 Images

After upgrading your project using this guide, the Liferay Cloud image versions are no longer set with the gradle.properties file. They are specified inside of the LCP.json directly in order to facilitate easier deployment using the Liferay Cloud CLI. Apply these image updates directly to the LCP.json files

Once the LCP.json files contains the updates, commit the changes to your Git repository.

git add gradle.properties && git commit -m "update dxp cloud stack to 2020.24.1"

After pushing these changes to the remote repository, a build will be created in Liferay Cloud and it is ready to deploy.

Version 4 Change Log

Version 3 DXP Stack 2020.24.1 

Version 3 Update Instructions

To apply these updates, update the gradle.properties file the project root folder with the new docker image tags. Here is an example of applying update 2020.24.1 for a 7.2 Liferay project:

liferay.workspace.lcp.backup.image=liferaycloud/backup:3.2.13
liferay.workspace.lcp.database.image=liferaycloud/database:3.2.10
liferay.workspace.lcp.search.image=liferaycloud/elasticsearch:6.8.6-3.0.8
liferay.workspace.lcp.liferay.image=liferaycloud/liferay-dxp:7.2.10-sp1-fp5-3.0.23
liferay.workspace.lcp.webserver.image=liferaycloud/nginx:1.16.1-3.2.0
liferay.workspace.lcp.jenkins.image=liferaycloud/jenkins:2.190.1-3.2.5

Once the gradle.properties file contains the updates, commit the changes to your Git repository.

git add gradle.properties && git commit -m "update dxp cloud stack to 2020.24.1"

After pushing these changes to the remote repository, a build will be created in Liferay Cloud and it is ready to deploy.

Version 3 Change Log