Merge pull request #2 from wblankenship/onbuilds

Detect if base image uses buildpack-deps
This commit is contained in:
Tianon Gravi 2015-04-03 15:28:21 -06:00
commit 78c8ed02e2
12 changed files with 34 additions and 16 deletions

View File

@ -0,0 +1,7 @@
# Image Variants
The `%%REPO%%` images come in many flavors, each designed for a specific use case.
## `%%REPO%%:<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.

View File

@ -4,4 +4,4 @@ The `%%REPO%%` images come in many flavors, each designed for a specific use cas
## `%%REPO%%:<version>` ## `%%REPO%%:<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. 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.

View File

@ -9,9 +9,10 @@ if [ -z "$repo" ]; then
fi fi
dir="$(dirname "$(readlink -f "$BASH_SOURCE")")" dir="$(dirname "$(readlink -f "$BASH_SOURCE")")"
url='https://raw.githubusercontent.com/docker-library/official-images/master/library/'"$repo"
IFS=$'\n' IFS=$'\n'
tags=( $(curl -sSL 'https://raw.githubusercontent.com/docker-library/official-images/master/library/'"$repo" | grep -vE '^$|^#' | cut -d':' -f1 | sort -u) ) tags=( $(curl -sSL "$url" | grep -vE '^$|^#' | cut -d':' -f1 | sort -u) )
unset IFS unset IFS
text= text=
@ -23,9 +24,19 @@ for tag in "${tags[@]}"; do
fi fi
done done
if [ "$text" ]; then if [ "$text" ]; then
latest=($(curl -sSL "$url" | grep "latest.*github.com" | sed -e 's!git://github.com/!!' -e 's/@/ /' -))
if [ -z "latest" ]; then
exit 0 # If not github or no latest tag, we are done here
fi
dockerfile='https://raw.githubusercontent.com/'"${latest[1]}"'/'"${latest[2]}"'/'"${latest[3]}"'/Dockerfile'
baseImage=$(curl -sSL $dockerfile | sed 's/:/\t/' | awk '$1 == "FROM" { print $2 }')
# give a little space # give a little space
echo echo
echo echo
cat "$dir/variant.md" if [ "$baseImage" = "buildpack-deps" ]; then
cat "$dir/variant-buildpacks.md"
else
cat "$dir/variant.md"
fi
echo "$text" echo "$text"
fi fi

View File

@ -54,11 +54,11 @@ The `django` images come in many flavors, each designed for a specific use case.
## `django:<version>` ## `django:<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. 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.
## `django:onbuild` ## `django:onbuild`
This image makes building derivitative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM django: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 django:onbuild` will be enough to create a stand-alone image for your project.
# License # License

View File

@ -72,7 +72,7 @@ This is the defacto image. If you are unsure about what your needs are, you prob
## `golang:onbuild` ## `golang:onbuild`
This image makes building derivitative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM golang: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 golang:onbuild` will be enough to create a stand-alone image for your project.
# License # License

View File

@ -47,7 +47,7 @@ This is the defacto image. If you are unsure about what your needs are, you prob
## `iojs:onbuild` ## `iojs:onbuild`
This image makes building derivitative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM iojs: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 iojs:onbuild` will be enough to create a stand-alone image for your project.
## `iojs:slim` ## `iojs:slim`

View File

@ -43,11 +43,11 @@ The `maven` images come in many flavors, each designed for a specific use case.
## `maven:<version>` ## `maven:<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. 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.
## `maven:onbuild` ## `maven:onbuild`
This image makes building derivitative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM maven: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 maven:onbuild` will be enough to create a stand-alone image for your project.
# License # License

View File

@ -52,11 +52,11 @@ The `mono` images come in many flavors, each designed for a specific use case.
## `mono:<version>` ## `mono:<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. 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.
## `mono:onbuild` ## `mono:onbuild`
This image makes building derivitative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM mono: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 mono:onbuild` will be enough to create a stand-alone image for your project.
# License # License

View File

@ -60,7 +60,7 @@ This is the defacto image. If you are unsure about what your needs are, you prob
## `node:onbuild` ## `node:onbuild`
This image makes building derivitative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM node: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 node:onbuild` will be enough to create a stand-alone image for your project.
## `node:slim` ## `node:slim`

View File

@ -58,7 +58,7 @@ This is the defacto image. If you are unsure about what your needs are, you prob
## `pypy:onbuild` ## `pypy:onbuild`
This image makes building derivitative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM pypy: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 pypy:onbuild` will be enough to create a stand-alone image for your project.
## `pypy:slim` ## `pypy:slim`

View File

@ -55,11 +55,11 @@ The `rails` images come in many flavors, each designed for a specific use case.
## `rails:<version>` ## `rails:<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. 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.
## `rails:onbuild` ## `rails:onbuild`
This image makes building derivitative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM rails: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 rails:onbuild` will be enough to create a stand-alone image for your project.
# License # License

View File

@ -66,7 +66,7 @@ This is the defacto image. If you are unsure about what your needs are, you prob
## `ruby:onbuild` ## `ruby:onbuild`
This image makes building derivitative images easier. For most use cases, creating a `Dockerfile` in the base of your project directory with the line `FROM ruby: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 ruby:onbuild` will be enough to create a stand-alone image for your project.
## `ruby:slim` ## `ruby:slim`