need to manage PG_VERSION better

[mgage]

also related #873

[mgage]

Mike:
Originally that was a link to pg/VERSION so that you could change the version
locally in pg/directory. You needed a link because CourseConfiguration.pm can’t
read things in the PG directory.

Later there were some other issues, I believe with docker, that couldn’t follow links
so PG_VERSION became a file and pg/VERSION is unused. You can delete it.

Alex Jordan:
OK, but then doesn't that mean that my page footer could be displaying "PG-2.14"
but actually my pg is checked out to the develop branch, or 2.13, or something?
That seems like it could be harmful for debugging and pull request testing.
Mike:
You are right about that. This is probably needs to be revisited.
We’ll work on a longer term solution.

History:
Docker had webwork2
as code but the pg directory was virtual and not loaded initially so the link pointed to empty space.

Updated docker config files from
@taniwallach
taniwallach committed on Sep 3, 2018
https://github.com/taniwallach/ww_docker_config_sets/tree/master/WW-2.14-ubuntu_16.04
which overcome several issues:

• docker-compose.yml: MariaDB on Dockers CE for Windows cannot function with bind mounted /var/lib/mysql at least with the default settings. Using a named volume for the persistent storage instead.
• Dockerfile: Hardwired the PG branch (@mgage) and merge ENV lines (@nmoller), and additional reorganization
• docker-entrypoint.sh: Create modelCourse directory and automatically run OPL-update on initial container startup, misc additional start-up time actions (@taniwallach)
• Add some additional files to .dockerignore
• PG_VERSION as a file, to match what the Dockerfile uses, so that the symbolic link cannot cause trouble/confusion in Docker installs.

This was in response to #873 and similar issues.

Any ideas on how to resolve this?

[taniwallach]

I don't recall exactly what the problem with was when Docker used the symbolic link, but I assume it somehow sometimes interfered with bringing up the Docker image. I do recall that getting the symbolic links to work properly with Docker on Windows was not as simple or straightforward as it is on Linux, and that it may not have handled things smoothly for some reason in some configuration tested. (Using one or both of webwork2 and/or pg from the local copy on the host computer or from inside the Docker image may matter in when the problem comes up or not.)

I think one possible resolution would be to try the following:

1. Return to using a symbolic link in general (best for regular installs).
2. Add a static version (PG_VERSION_DOCKER) which can be used by Docker installs (maybe call the version inside the file something like "unknown-pg-version-docker").
3. Either have Dockerfile or docker-compose.yml replace the standard symbolic link with a copy of the static version in the image/container at build or startup time.

• 2-3 are intended to try to avoid whatever issue was sometimes occurring when a symbolic link was used with Docker in whatever configuration had the problem.

4. Use docker-entrypoint.sh to try to update the existing PG_VERSION file in a running image (at startup) by copying ../pg/VERSION to PG_VERSION. (If the file is a symbolic link, it should probably be deleted before the copy is made.)

Probably step 4 alone would provide a short-term resolution for Docker users.

I don't have time to test this out now.

[mgage]

That’s about my memory as well. When you first download the docker file you had a link pointing to nowhere and that caused a problem on some machines. I can’t test it on windows easily but I can test it on a mac (which is probably good enough for unix machines). I think I’ll try 1 and 2 (PG_VERSION_DOCKER) and have the docker files reference that. For now I’ll keep the “VERSION” file in pg and have the browser reference that. The PG_VERSION_DOCKER will only be used by DOCKER to figure out which PG version to download. (Originally we were trying to derive this from the WEBWORK2 version which broke because I wasn’t completely consistent about version names. ) Some self discipline may allow us to go back to that method. :-) Take care, Mike

[taniwallach]

The current Dockerfile sets an ENV variable called PG_BRANCH (near the top of the file) which is used to determine which version of pg to download and install in the Docker image.

I think that now the PG_VERSION file is only used to pull in the version string to display on the page footer.

With some Docker config (I suspect under Windows) the symbolic link made trouble.

Step 3 was intended to "trick" Docker into using the special file instead of the "regular" symbolic link.

[mgage]

This is (will be) fixed in commit 3f4777f
which is currently part of PR #930.

There are some modifications to CourseEnvironment.pm which normally only reads files in the
webwork2/conf directory to make an exception and read the file pg/VERSION when setting up the course environment. The file webwork2/PG_VERSION is a no-op at this point. The PG version to be downloaded by docker is specified explicitly in the Dockerfile and has to be updated manually as versions change.

[mgage]

webwork2/PG_VERSION is removed in WeBWorK-2.15

[drgrice1]

I think this is fixed.