Bug: Running using documented Docker documentation fails

[e-lo]

Bug report

Describe the bug
I followed the directions in readme.md for running app via Docker but it did not work. Suspect documentation just needs to be adjusted.

How we reproduce the bug
Steps to reproduce the behaviour:

1. docker pull ghcr.io/mobilitydata/gtfs-validator
2. docker run -v /myDirectory:/theContainerDirectory -it ghcr.io/mobilitydata/gtfs-validator:latest (with appropriate substitutions)
3. java -jar gtfs-validator-v-snapshot_cli.jar -u https://content.amtrak.com/content/gtfs/GTFS.zip (or whatever .zip)_

Expected behaviour
Runs validator on specified URL or file.

Observed behaviour
Opens a Java command line // which failes with the java -jar command.

Environment versions

• validator version: as specified in Dockerfile
• Java version: as specified in Dockerfile
• OS versions: OSX 11.6.4

[derhuerst]

When fixing this bug, the ergonomics of the Docker image could also be improved:

• If you add an ENTRYPOINT directive to the Dockerfile, I could specify the URL to validate directly with the docker run command, without having to enter it into the shell as currently documented.
• Changing the workday to an app/utility-specific directory (e.g. /app) instead of / is a best practice, because figuring out which tools are available to run is a lot easier then.
• The docker pull in the docs is optional, docker run will pull automatically if the image is missing. If you want to force updating the image, you can pass --pull always to docker run (but I can see that this makes the command more confusing).
• You could use a "slim" openjdk Docker base image, which doesn't have the full Debian Linux userland, but a slimmed down version, usually Alpine Linux. This reduces size and speed of the Docker image.

[themightychris]

My pull request #1120 implements much of @derhuerst 's suggestions above—would love your feedback over there!