Closed ghost closed 1 day ago
Dragan Ivanovic 3 days ago Only bin, rdf and config files are copied into VIVO_HOME, right? I suppose some changes might happened into config and rdf in customized VIVO instances. I see the next scenarios:
I suppose the first two scenarios are not a problem. @William Welling is manual creation of digest only solution for 3rd scenario (in the case when docker is not used), or it is also working for 4th scenario? Do you see any other scenario? We can add instructions for upgrading VIVO somewhere in wiki documentation. If it is just one command, I hope it wouldn't be a problem.
_1. An institution is installing VIVO for the first time, there is only empty VIVOHOME directory.
There is always a VIVO home directory now and not defined at build time but rather runtime. Previously, the maven process could have created the home directory if not exist.
_2. An institution is upgrading VIVO, but didn't customized VIVOHOME, meaning didn't change any single file in rdf and config.
Upgrade will handle the rest now knowing there is a digest provided of the VIVO home directory.
_3. An institution is upgrading VIVO to some future VIVO which is not changing any file which should be copied to config or rdf subdirectories of VIVO_HOME, but institution customized its previous VIVO version by changing something in VIVO_HOME/config or VIVOHOME/rdf.
Are there any home bin, config or rdf file changes on upgrade?
Has the instance of VIVO been tampered with? i.e. has the system administrator, developers, or other personnel that have access to the terminal changed them? We have a known use case in which they are mutated but versioned in a fork. If implementer continues to build from source the VIVO application, they continue to do so but have to provide there VIVO home digest on restart or it may be in an uncertain state. Is a useful thing to know when restarting to avoid having graph dumped into your production triplestore.
_4. An institution is upgrading VIVO to some future VIVO which is changing some files which should be copied to config or rdf subdirectories of VIVO_HOME (introducing new property in default.runtime.properties, adding new n3 file in rdf, etc.), and institution also customized its previous VIVO version by changing something in VIVO_HOME/config or VIVOHOME/rdf.
The customizations described here are most likely made in a repository fork and applied before build. Which means everything would work as expected.
Merge conflicts with https://github.com/vivo-project/VIVO/pull/3940.
This is a follow-on PR to https://github.com/vivo-project/VIVO/pull/3839 and can be handled two ways; review this PR in place of https://github.com/vivo-project/VIVO/pull/3839 or maintain commits of branched PR by not squash merging.
VIVO GitHub issue: https://github.com/vivo-project/VIVO/issues/3822 and https://github.com/vivo-project/VIVO/issues/3786
Also related to https://github.com/vivo-project/VIVO/issues/3698 as the docker deployment supports specifying the Tomcat webapp context path.
What does this pull request do?
What's new?
Updates to the Dockerfile, docker-compose.yml, and start.sh script among other deployment related configuration files.
How should this be tested?
See README.md
Interested parties
@chenejac