Steps to follow to set up Docker 3.2:

Unzip the Docker release package, Create a new folder and paste the kit you use from the package. You can also replace your existing kit with the new release's kit but will need to save your docker-compose file to reuse.

Changes in docker-compose file: This file can be set up in a similar way you did for the previous Docker version. For detailed information you can take a look at this documentation

Before you build and start this new Docker version make sure you do not have the previous Docker version running. The way to do that is by using docker-compose ps. If there are no containers, then you can proceed to the next step, else either stop the Docker containers using docker-compose stop.

Rebuild the Docker by using docker-compose build -force-rm. This will download and pull down all the changes in the new release.

Once everything is successfully built, run the docker by using docker-compose up -d.

To check if all the containers are up and running use docker-compose ps and can to check the logs use docker-compose logs -f {containerID}

Rebuild Project Search Index

This step is required to be done.

The Search indexes in the Elastic Search version 1.7.1 and 6.2.4 are not compatible. All the content and the data will be restored as the previous version but only the Search would not work. It is recommended to re-build the indexes.

To rebuild the search indexes:

Go to Project

Go to Manage Project

Go to the Tools Page from the Left Navigation

Click on Rebuild Search Index

This will populate all the search indexes.

Re-index the Project Data Stores

This is an optional step. This option will walk over the project data stores and re-index any collections to make sure that they are optimized for performance.

To re-index the Project Data Stores:

Go to Project

Go to Manage Project

Go to the Tools Page from the Left Navigation

Click on Index Project Data Stores

Changes for Custom Modules:

In the new release we have just changed the naming conventions of the contexts and sub-contexts in the configuration files i.e the JSON files that define the layout of the page.

We have context and sub-context block in the configuration that define the menus and sub-menus to display for every page. Previously for every config file, we commonly wrote just context to define the context and just sub-context to define the sub-context be it application, project, data lists etc but became more specific with these in the new release in the sense that Project context will now be written as project-context instead of just context, Similarly Application sub-context will be written as application-subcontext instead of just subcontext.

Following images show the difference in the naming convention of the context in the config of Project.

In the previous release, in the config block of the context-project evaluator, the context was named as context as you can see here

Whereas, in this release we renamed it to project-context as follows

Similarly for the sub-context, lets say in the role.json the subcontext is replaced by role-subcontext as follows

If any custom modules make any changes in these files, then it will need to make such changes in the configuration of that page.

Re-enable SNS notifications:

Prior to 3.2 SNS was the default notification provider. To continue using SNS you must change the Spring "bean" definition in the API config file {kit folder}/api/classes/gitana/distributions/cloudcms-docker-context.xml