Closed bschmalhofer closed 4 years ago
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.
@bschmalhofer please test fix on branch issue_95_fix
.
Hello Juan,
I have taken a look at issue_95_fix
and tested it with the following steps:
issue_95_fix
touch .env
so that docker build is happydocker build
created an image with the tag latest
sudo systemctl stop apache2.service
in order to make port 80 availabledocker-compose -f docker-compose-prod.yml up
Start the version from Docker Hubdocker-compose -f docker-compose-prod.yml ps
to doublecheck whether the container is runningdocker exec -it docker-otrs_otrs_1 bash
touch /opt/otrs/Kernel/dummy_from_master_branch
for double checkingexit
go back to the Docker hostdocker-compose -f docker-compose-prod.yml down
docker-compose -f docker-compose-prod.yml up
docker exec -it docker-otrs_otrs_1 bash
I did the following sanity checks:
[x] /opt/otrs/Kernel/current_release is 6.0.28
[x] /opt/otobo/Kernel/dummy_from_master_branch still exists
[x] docker logs docker-otrs_otrs_1 | grep minor
[x] /Kernel is gone
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!
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.
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.
Fix merged, thanks for reporting.
Hi, I am working on improving the Docker support for OTOBO, specifically https://github.com/RotherOSS/otobo/issues/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.
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 ?