Update variant helpers with the same logic as the tags helper

.template-helpers/variant-alpine.md

@@ -1,4 +1,4 @@
-## `%%REPO%%:alpine`
+## `%%IMAGE%%:alpine`
 
 This image is based on the popular [Alpine Linux project](http://alpinelinux.org), available in [the `alpine` official image](https://hub.docker.com/_/alpine). Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.
 

.template-helpers/variant-buildpacks.md

@@ -1,7 +1,7 @@
 # Image Variants
 
-The `%%REPO%%` images come in many flavors, each designed for a specific use case.
+The `%%IMAGE%%` images come in many flavors, each designed for a specific use case.
 
-## `%%REPO%%:<version>`
+## `%%IMAGE%%:<version>`
 
 This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of [`buildpack-deps`](https://registry.hub.docker.com/_/buildpack-deps/). `buildpack-deps` is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.

.template-helpers/variant-onbuild.md

@@ -1,6 +1,6 @@
-## `%%REPO%%:onbuild`
+## `%%IMAGE%%:onbuild`
 
-This image makes building derivative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM %%REPO%%:onbuild` will be enough to create a stand-alone image for your project.
+This image makes building derivative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM %%IMAGE%%:onbuild` will be enough to create a stand-alone image for your project.
 
 While the `onbuild` variant is really useful for "getting off the ground running" (zero to Dockerized in a short period of time), it's not recommended for long-term usage within a project due to the lack of control over *when* the `ONBUILD` triggers fire (see also [`docker/docker#5714`](https://github.com/docker/docker/issues/5714), [`docker/docker#8240`](https://github.com/docker/docker/issues/8240), [`docker/docker#11917`](https://github.com/docker/docker/issues/11917)).
 

.template-helpers/variant-slim.md

@@ -1,3 +1,3 @@
-## `%%REPO%%:slim`
+## `%%IMAGE%%:slim`
 
-This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `%%REPO%%`. Unless you are working in an environment where *only* the %%REPO%% image will be deployed and you have space constraints, we highly recommend using the default image of this repository.
+This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `%%IMAGE%%`. Unless you are working in an environment where *only* the `%%IMAGE%%` image will be deployed and you have space constraints, we highly recommend using the default image of this repository.

.template-helpers/variant-windowsservercore.md

@@ -1,4 +1,4 @@
-## `%%REPO%%:windowsservercore`
+## `%%IMAGE%%:windowsservercore`
 
 This image is based on [Windows Server Core (`microsoft/windowsservercore`)](https://hub.docker.com/r/microsoft/windowsservercore/). As such, it only works in places which that image does, such as Windows 10 Professional/Enterprise (Anniversary Edition) or Windows Server 2016.
 

.template-helpers/variant.md

@@ -1,7 +1,7 @@
 # Image Variants
 
-The `%%REPO%%` images come in many flavors, each designed for a specific use case.
+The `%%IMAGE%%` images come in many flavors, each designed for a specific use case.
 
-## `%%REPO%%:<version>`
+## `%%IMAGE%%:<version>`
 
 This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.

.template-helpers/variant.sh

@@ -10,10 +10,14 @@ fi
 
 dir="$(dirname "$(readlink -f "$BASH_SOURCE")")"
 repoDir="$dir/../$repo"
-url='https://raw.githubusercontent.com/docker-library/official-images/master/library/'"$repo"
+
+# if we haven't set BASHBREW_LIBRARY explicitly (like Jenkins does, for example), don't trust the local library
+if [ -z "${BASHBREW_LIBRARY:-}" ]; then
+	repo="https://github.com/docker-library/official-images/raw/master/library/$repo"
+fi
 
 IFS=$'\n'
-tags=( $(bashbrew cat -f '{{ range .Entries }}{{ join "\n" .Tags }}{{ "\n" }}{{ end }}' "$url") )
+tags=( $(bashbrew cat -f '{{ range .Entries }}{{ join "\n" .Tags }}{{ "\n" }}{{ end }}' "$repo") )
 unset IFS
 
 text=
@@ -29,7 +33,7 @@ for tag in "${tags[@]}"; do
 done
 
 if [ "$text" ]; then
-	baseImage="$(bashbrew cat -f '{{ .DockerFrom .TagEntry }}' "$url":latest)"
+	baseImage="$(bashbrew cat -f '{{ .DockerFrom .TagEntry }}' "$repo":latest)"
 	baseImage="${baseImage%:*}"
 
 	echo