Merge pull request #172 from infosiftr/onbuilds
Initial onbuild/slim description generation
This commit is contained in:
Tianon Gravi
commit
4f02214a70
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
For more information about this image and its history, please see the [relevant manifest file (`library/%%REPO%%`)](https://github.com/docker-library/official-images/blob/master/library/%%REPO%%) in the [`docker-library/official-images` GitHub repo](https://github.com/docker-library/official-images).
|
||||
|
||||
%%CONTENT%%%%LICENSE%%
|
||||
%%CONTENT%%%%VARIANT%%%%LICENSE%%
|
||||
|
||||
# Supported Docker versions
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
## `%%REPO%%: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.
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
## `%%REPO%%: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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
#!/bin/bash
|
||||
set -e
|
||||
|
||||
repo="$1"
|
||||
if [ -z "$repo" ]; then
|
||||
echo >&2 "usage: $0 repo"
|
||||
echo >&2 " ie: $0 hylang"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
dir="$(dirname "$(readlink -f "$BASH_SOURCE")")"
|
||||
url='https://raw.githubusercontent.com/docker-library/official-images/master/library/'"$repo"
|
||||
|
||||
IFS=$'\n'
|
||||
tags=( $(curl -sSL "$url" | grep -vE '^$|^#' | cut -d':' -f1 | sort -u) )
|
||||
unset IFS
|
||||
|
||||
text=
|
||||
for tag in "${tags[@]}"; do
|
||||
if [ -f "$dir/variant-${tag}.md" ]; then
|
||||
text+=$'\n' # give a little space
|
||||
# because parameter expansion eats the trailing newline
|
||||
text+="$(<"$dir/variant-${tag}.md")"$'\n'
|
||||
fi
|
||||
done
|
||||
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
|
||||
echo
|
||||
echo
|
||||
if [ "$baseImage" = "buildpack-deps" ]; then
|
||||
cat "$dir/variant-buildpacks.md"
|
||||
else
|
||||
cat "$dir/variant.md"
|
||||
fi
|
||||
echo "$text"
|
||||
fi
|
||||
|
|
@ -48,6 +48,18 @@ If you want to generate the scaffolding for a new Django project, you can do the
|
|||
|
||||
This will create a sub-directory named `mysite` inside your current directory.
|
||||
|
||||
# Image Variants
|
||||
|
||||
The `django` images come in many flavors, each designed for a specific use case.
|
||||
|
||||
## `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.
|
||||
|
||||
## `django: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 django:onbuild` will be enough to create a stand-alone image for your project.
|
||||
|
||||
# License
|
||||
|
||||
View [license information](https://github.com/django/django/blob/master/LICENSE) for the software contained in this image.
|
||||
|
|
|
|||
|
|
@ -62,6 +62,18 @@ Alternatively, you can build for multiple platforms at once:
|
|||
> done
|
||||
> done
|
||||
|
||||
# Image Variants
|
||||
|
||||
The `golang` images come in many flavors, each designed for a specific use case.
|
||||
|
||||
## `golang:<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.
|
||||
|
||||
## `golang: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 golang:onbuild` will be enough to create a stand-alone image for your project.
|
||||
|
||||
# License
|
||||
|
||||
View [license information](http://golang.org/LICENSE) for the software contained in this image.
|
||||
|
|
|
|||
|
|
@ -37,6 +37,22 @@ To run a single script, you can mount it in a volume under `/usr/src/app`. From
|
|||
|
||||
$ docker run -v ${PWD}:/usr/src/app -w /usr/src/app --it --rm iojs iojs index.js
|
||||
|
||||
# Image Variants
|
||||
|
||||
The `iojs` images come in many flavors, each designed for a specific use case.
|
||||
|
||||
## `iojs:<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.
|
||||
|
||||
## `iojs: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 iojs:onbuild` will be enough to create a stand-alone image for your project.
|
||||
|
||||
## `iojs:slim`
|
||||
|
||||
This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `iojs`. Unless you are working in an environment where *only* the iojs image will be deployed and you have space constraints, we highly recommend using the default image of this repository.
|
||||
|
||||
# License
|
||||
|
||||
View [license information](https://github.com/iojs/io.js/blob/master/LICENSE) for the software contained in this image.
|
||||
|
|
|
|||
|
|
@ -35,6 +35,18 @@ For many simple projects, you may find it inconvenient to write a complete `Dock
|
|||
|
||||
docker run -it --rm --name my-maven-project -v "$PWD":/usr/src/mymaven -w /usr/src/mymaven maven:3.2-jdk-7 mvn clean install
|
||||
|
||||
# Image Variants
|
||||
|
||||
The `maven` images come in many flavors, each designed for a specific use case.
|
||||
|
||||
## `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.
|
||||
|
||||
## `maven: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 maven:onbuild` will be enough to create a stand-alone image for your project.
|
||||
|
||||
# License
|
||||
|
||||
View [license information](https://www.apache.org/licenses/) for the software contained in this image.
|
||||
|
|
|
|||
|
|
@ -46,6 +46,18 @@ This Docker image is provided by Xamarin, for users of the Mono Project.
|
|||
|
||||
Thanks to [Michael Friis](http://friism.com/) for his preliminary work.
|
||||
|
||||
# Image Variants
|
||||
|
||||
The `mono` images come in many flavors, each designed for a specific use case.
|
||||
|
||||
## `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.
|
||||
|
||||
## `mono: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 mono:onbuild` will be enough to create a stand-alone image for your project.
|
||||
|
||||
# License
|
||||
|
||||
This Docker Image is licensed with the Expat License. See the [Mono Project licensing FAQ](http://www.mono-project.com/docs/faq/licensing/) for details on how Mono and associated libraries are licensed.
|
||||
|
|
|
|||
|
|
@ -50,6 +50,22 @@ For many simple, single file projects, you may find it inconvenient to write a c
|
|||
|
||||
docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp node:0.10 node your-daemon-or-script.js
|
||||
|
||||
# Image Variants
|
||||
|
||||
The `node` images come in many flavors, each designed for a specific use case.
|
||||
|
||||
## `node:<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.
|
||||
|
||||
## `node: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 node:onbuild` will be enough to create a stand-alone image for your project.
|
||||
|
||||
## `node:slim`
|
||||
|
||||
This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `node`. Unless you are working in an environment where *only* the node image will be deployed and you have space constraints, we highly recommend using the default image of this repository.
|
||||
|
||||
# License
|
||||
|
||||
View [license information](https://github.com/joyent/node/blob/master/LICENSE) for the software contained in this image.
|
||||
|
|
|
|||
|
|
@ -48,6 +48,22 @@ or (again, if you need to use Python 2):
|
|||
|
||||
docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp pypy:2 pypy your-daemon-or-script.py
|
||||
|
||||
# Image Variants
|
||||
|
||||
The `pypy` images come in many flavors, each designed for a specific use case.
|
||||
|
||||
## `pypy:<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.
|
||||
|
||||
## `pypy: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 pypy:onbuild` will be enough to create a stand-alone image for your project.
|
||||
|
||||
## `pypy:slim`
|
||||
|
||||
This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `pypy`. Unless you are working in an environment where *only* the pypy image will be deployed and you have space constraints, we highly recommend using the default image of this repository.
|
||||
|
||||
# License
|
||||
|
||||
View [license information](https://bitbucket.org/pypy/pypy/src/c3ff0dd6252b6ba0d230f3624dbb4aab8973a1d0/LICENSE?at=default) for software contained in this image.
|
||||
|
|
|
|||
|
|
@ -52,6 +52,22 @@ or (again, if you need to use Python 2):
|
|||
|
||||
docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp python:2 python your-daemon-or-script.py
|
||||
|
||||
# Image Variants
|
||||
|
||||
The `python` images come in many flavors, each designed for a specific use case.
|
||||
|
||||
## `python:<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.
|
||||
|
||||
## `python: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 python:onbuild` will be enough to create a stand-alone image for your project.
|
||||
|
||||
## `python:slim`
|
||||
|
||||
This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `python`. Unless you are working in an environment where *only* the python image will be deployed and you have space constraints, we highly recommend using the default image of this repository.
|
||||
|
||||
# License
|
||||
|
||||
View license information for [Python 2](https://docs.python.org/2/license.html) and [Python 3](https://docs.python.org/3/license.html).
|
||||
|
|
|
|||
|
|
@ -49,6 +49,18 @@ If you want to generate the scaffolding for a new Rails project, you can do the
|
|||
|
||||
This will create a sub-directory named `webapp` inside your current directory.
|
||||
|
||||
# Image Variants
|
||||
|
||||
The `rails` images come in many flavors, each designed for a specific use case.
|
||||
|
||||
## `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.
|
||||
|
||||
## `rails: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 rails:onbuild` will be enough to create a stand-alone image for your project.
|
||||
|
||||
# License
|
||||
|
||||
View [license information](https://github.com/rails/rails#license) for the software contained in this image.
|
||||
|
|
|
|||
|
|
@ -52,6 +52,22 @@ For many simple, single file projects, you may find it inconvenient to write a c
|
|||
|
||||
docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp ruby:2.1 ruby your-daemon-or-script.rb
|
||||
|
||||
# Image Variants
|
||||
|
||||
The `ruby` images come in many flavors, each designed for a specific use case.
|
||||
|
||||
## `ruby:<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.
|
||||
|
||||
## `ruby: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 ruby:onbuild` will be enough to create a stand-alone image for your project.
|
||||
|
||||
## `ruby:slim`
|
||||
|
||||
This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run `ruby`. Unless you are working in an environment where *only* the ruby image will be deployed and you have space constraints, we highly recommend using the default image of this repository.
|
||||
|
||||
# License
|
||||
|
||||
View [license information](https://www.ruby-lang.org/en/about/license.txt) for the software contained in this image.
|
||||
|
|
|
|||
|
|
@ -110,6 +110,9 @@ for repo in "${repos[@]}"; do
|
|||
echo ' CONTENT => '"$repo"'/content.md'
|
||||
replace_field "$repo" 'CONTENT' "$(cat "$repo/content.md")"
|
||||
|
||||
echo ' VARIANT => variant.sh'
|
||||
replace_field "$repo" 'VARIANT' "$("$helperDir/variant.sh" "$repo")"
|
||||
|
||||
# has to be after CONTENT because it's contained in content.md
|
||||
echo " LOGO => $logo"
|
||||
replace_field "$repo" 'LOGO' "$logo" '\s*'
|
||||
|
|
|
|||
Loading…
Reference in New Issue