fixup! feat(docker): Migrate BUILD_GRAPHS to REBUILD_GRAPHS

docs/run-instance/installation/running-with-docker.md

@@ -92,7 +92,7 @@ There are multiple ways with Docker to quickly have a running instance.
       -v $PWD/docker/logs/tomcat:/home/ors/tomcat/logs \
       -v $PWD/docker/conf:/home/ors/ors-conf \
       -v $PWD/docker/data:/home/ors/ors-core/data \
-      #-e "BUILD_GRAPHS=True" \
+      #-e "REBUILD_GRAPHS=True" \
       -e "JAVA_OPTS=-Djava.awt.headless=true -server -XX:TargetSurvivorRatio=75 -XX:SurvivorRatio=64 -XX:MaxTenuringThreshold=3 -XX:+UseG1GC -XX:+ScavengeBeforeFullGC -XX:ParallelGCThreads=4 -Xms1g -Xmx2g" \
       -e "CATALINA_OPTS=-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9001 -Dcom.sun.management.jmxremote.rmi.port=9001 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=localhost" \
       openrouteservice/openrouteservice:latest 
@@ -114,7 +114,7 @@ There are multiple ways with Docker to quickly have a running instance.
       -v $PWD/docker/logs/tomcat:/home/ors/tomcat/logs \
       -v $PWD/docker/conf:/ors-conf \
       -v $PWD/docker/data:/ors-core/data \
-      #-e "BUILD_GRAPHS=True" \
+      #-e "REBUILD_GRAPHS=True" \
       -e "JAVA_OPTS=-Djava.awt.headless=true -server -XX:TargetSurvivorRatio=75 -XX:SurvivorRatio=64 -XX:MaxTenuringThreshold=3 -XX:+UseG1GC -XX:+ScavengeBeforeFullGC -XX:ParallelGCThreads=4 -Xms1g -Xmx2g" \
       -e "CATALINA_OPTS=-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9001 -Dcom.sun.management.jmxremote.rmi.port=9001 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=localhost" \
       openrouteservice/openrouteservice:v6.8.1
@@ -164,12 +164,12 @@ For detailed information on the settings you can make, see the chapter on [confi
 
 Old ORS configuration files in JSON format are **deprecated**. If you have a custom `ors-config.json` file from a previous installation we strongly recommend to migrate to the new YAML format. For the transitional period ORS allows the use of old format JSON files placed at `./docker/conf/ors-config.json`. All settings in such a file, if present, will override settings in the proper YAML format.
 
-If you are making changes to anything relating to the OSM data or the settings that change how graphs are built, you need to delete the folders in `graphs` or set the environment variable `BUILD_GRAPHS=True` (see comment in Dockerfile or examples above). This makes it so that the graphs are built again with the new data/settings.
+If you are making changes to anything relating to the OSM data or the settings that change how graphs are built, you need to delete the folders in `graphs` or set the environment variable `REBUILD_GRAPHS=True` (see comment in Dockerfile or examples above). This makes it so that the graphs are built again with the new data/settings.
 
 ### Different OSM file
 To change the OSM data that is used, you can either overwrite the `docker/data/osm_file.pbf` file, or modify the volume mount of `/home/ors/ors-core/data` to a directory containing a file `osm_file.pbf`, or volume mount something like  `/YOUR/PATH/TO/ANOTHER/OSM_FILE.pbf:/home/ors/ors-core/data/osm_file.pbf`. 
 
-Make sure to set the environment variable `BUILD_GRAPHS=True` or empty the `docker/graphs/` directory before restarting the container.
+Make sure to set the environment variable `REBUILD_GRAPHS=True` or empty the `docker/graphs/` directory before restarting the container.
 
 If you are building the Docker image locally, you can also point the build argument `OSM_FILE` to your desired OSM file before building the image.
 
@@ -207,7 +207,7 @@ Look at the [`docker-compose.yml`](https://github.com/GIScience/openrouteservice
 
 ### Environment variables
 
-- `BUILD_GRAPHS`: Forces ORS to rebuild the routing graph(s) when set to `True`. Useful when another PBF is specified in the Docker volume mapping to `/home/ors/ors-core/data/osm_file.pbf`
+- `REBUILD_GRAPHS`: Forces ORS to rebuild the routing graph(s) when set to `True`. Useful when another PBF is specified in the Docker volume mapping to `/home/ors/ors-core/data/osm_file.pbf`
 - `JAVA_OPTS`: Custom Java runtime options, such as `-Xms` or `-Xmx`
 - `CATALINA_OPTS`: Custom Catalina options
 
@@ -223,4 +223,4 @@ When building the image, the following arguments are customizable:
 ## Instance infrastructure
 Though having a single container works great for smaller datasets or when the graph data doesn't need updating, in many real world implementations having just the one instance isn't the most suitable solution. If you have one container, then all building and serving of routes happens through that single container, meaning that when you rebuild graphs, you can't make any requests to that instance for things like directions as there are no complete graphs that can be used to generate routes with. If it is important that you have graph updates from new data whilst ensuring that there is a minimal amount of time during which users cannot make requests, we would recommend having two instances - one that is permanently active for serving requests, and one that gets fired up to rebuild graphs.
 
-In that setup, when graphs have been built you can simply stop the container serving requests, replace the graphs used (they are mapped to a folder on the host machine which is defined in the `docker-compose` file), and then restart the container. The new graphs will be reloaded into memory (the amount of time needed for this depends on the size of the graphs and the type of hard drive) and then ready to use for routing. The downtime from reloading already built graphs is normally far less than the time needed to build the graphs. A thing to note though is that you should ensure that the config files and the amount of RAM allocated (as described earlier) is the same on both the builder and the request server else the newly built graphs may not load. **Also, ensure that `BUILD_GRAPHS` parameter in the `docker-compose` file used by the request serving container is set to false else it will try to build the graphs for itself!**
+In that setup, when graphs have been built you can simply stop the container serving requests, replace the graphs used (they are mapped to a folder on the host machine which is defined in the `docker-compose` file), and then restart the container. The new graphs will be reloaded into memory (the amount of time needed for this depends on the size of the graphs and the type of hard drive) and then ready to use for routing. The downtime from reloading already built graphs is normally far less than the time needed to build the graphs. A thing to note though is that you should ensure that the config files and the amount of RAM allocated (as described earlier) is the same on both the builder and the request server else the newly built graphs may not load. **Also, ensure that `REBUILD_GRAPHS` parameter in the `docker-compose` file used by the request serving container is set to false else it will try to build the graphs for itself!**