Perl modules not being copied on minor update

[bschmalhofer]

Hi,
I am working on improving the Docker support for OTOBO, specifically RotherOSS/otobo#203 . Of course I'm looking at docker-otrs for ideas. Thank you for your inspiring work!

My understanding is that for a minor version, or patch level, upgrade at least two steps must be executed.

1. copy the config and Perl modules from /Kernel to /opt/otrs/Kernel
2. execute scripts/DBUpdate-to-6.pl --non-interactive

Step 1. seems to be handled in check_host_mount_dir. I understand that this function is called when firsttime is still present. But how can it be that the copying is actually done when there is the condition is:

if ([ "$(ls -A ${OTRS_CONFIG_MOUNT_DIR})" ] && [ ! "$(ls -A ${OTRS_CONFIG_DIR})" ]) || [ "${OTRS_UPGRADE}" == "yes" ];

$(ls -A ${OTRS_CONFIG_DIR}) is, as far as I understand it, true because the previous installation still exists in the mounted volume ./volumes/config . Setting$OTRS_UPGRADE="yes"`seems to be no option as this would trigger a major version upgrade. Did I miss anything or is this a bug in functions.sh ?

[juanluisbaptiste]

Hi,

That condition is in place to avoid overwriting custom modifications done inside /opt/otrs/Kernel (${OTRS_CONFIG_DIR}), so copying should be done when the container is started for the first time and the config volume is empty, or when doing a major version upgrade. But indeed that condition avoids copying updated modules on a minor update as the check sees if ${OTRS_CONFIG_DIR} is empty, but for a minor version upgrade it will not be empty so you are right, the modules will not be copied on that case.

I'm working on a patch right now to fix this behavior.

[juanluisbaptiste]

@bschmalhofer please test fix on branch issue_95_fix.

[bschmalhofer]

Hello Juan,

I have taken a look at issue_95_fixand tested it with the following steps:

• Checked out issue_95_fix
• touch .env so that docker build is happy
• docker build created an image with the tag latest
• Changed the otrs image in docker-compose-prod.yml to juanluisbaptiste/otrs:6.0.28
• sudo systemctl stop apache2.service in order to make port 80 available
• docker-compose -f docker-compose-prod.yml up Start the version from Docker Hub
• Change to another terminal
• docker-compose -f docker-compose-prod.yml ps to doublecheck whether the container is running
• docker exec -it docker-otrs_otrs_1 bash
• In the container: set /opt/otrs/Kernel/current_version to 0.0.1 in order to trigger a patch upgrade at the next start
• In the container: touch /opt/otrs/Kernel/dummy_from_master_branch for double checking
• exit go back to the Docker host
• docker-compose -f docker-compose-prod.yml down
• Changed the otrs image in docker-compose-prod.yml to juanluisbaptiste/otrs:latest
• docker-compose -f docker-compose-prod.yml up
• Change back to the first terminal
• docker exec -it docker-otrs_otrs_1 bash
• Check sanity

I did the following sanity checks:

• /opt/otrs/Kernel/current_release is 6.0.28

• /opt/otobo/Kernel/dummy_from_master_branch still exists

• docker logs docker-otrs_otrs_1 | grep minor

• /Kernel is gone

[bschmalhofer]

The above steps are not exactly the real steps, as I doubled up a couple of times.
The result look good and from my side the ticket can be closed.
Thanks for the fix!

[juanluisbaptiste]

It would be easier if you have used docker-compose-prod.yml to launch the OTRS 6.0.28 image first to create a new install, then stop it and use docker-compose.yml, update the Dockerfile to the latest versoin 6.0.29 (which I will update after I merge this fix), build it and launch it using the same volumes.

Anyway I'm glad it worked, I will merge the fix into master as soon as I can.

[bschmalhofer]

Yes, you are right. I realized only after the second try that the code checked against the DOCKER_VERSION that is defined in the Dockerfile.

[juanluisbaptiste]

Fix merged, thanks for reporting.