Adding Git Buildcontext

Gopkg.toml

@@ -33,12 +33,16 @@ required = [
 
 [[constraint]]
   name = "k8s.io/client-go"
-  version = "kubernetes-1.11.0"
+  version = "kubernetes-1.11.3"
 
 [[constraint]]
   name = "github.com/google/go-containerregistry"
-  revision = "88d8d18eb1bde1fcef23c745205c738074290515"
+  revision = "8621d738a07bc74b2adeafd175a3c738423577a0"
 
 [[override]]
   name = "k8s.io/apimachinery"
   version = "kubernetes-1.11.0"
+
+[[constraint]]
+  name = "gopkg.in/src-d/go-git.v4"
+  version = "4.6.0"

Makefile

@@ -20,6 +20,7 @@ VERSION_BUILD ?= 0
 VERSION ?= v$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_BUILD)
 VERSION_PACKAGE = $(REPOPATH/pkg/version)
 
+SHELL := /bin/bash
 GOOS ?= $(shell go env GOOS)
 GOARCH = amd64
 ORG := github.com/GoogleContainerTools

README.md

@@ -117,10 +117,14 @@ When running kaniko, use the `--context` flag with the appropriate prefix to spe
 | Local Directory  | dir://[path to a directory in the kaniko container]  |
 | GCS Bucket       | gs://[bucket name]/[path to .tar.gz]     |
 | S3 Bucket        | s3://[bucket name]/[path to .tar.gz]     |
+| Git Repository   | git://[repository url]     |
 
 If you don't specify a prefix, kaniko will assume a local directory.
 For example, to use a GCS bucket called `kaniko-bucket`, you would pass in `--context=gs://kaniko-bucket/path/to/context.tar.gz`.
 
+### Using Private Git Repository
+You can use `Personal Access Tokens` for Build Contexts from Private Repositories from [GitHub](https://blog.github.com/2012-09-21-easier-builds-and-deployments-using-git-over-https-and-oauth/).
+
 ### Running kaniko
 
 There are several different ways to deploy and run kaniko:
@@ -362,7 +366,7 @@ You can set it multiple times for multiple registries.
 
 #### --skip-tls-verify-registry
 
-Set this flag to skip TLS cerificate validation when accessing a registry. It is supposed to be useed for testing purposes only and should not be used in production!
+Set this flag to skip TLS cerificate validation when accessing a registry. It is supposed to be used for testing purposes only and should not be used in production!
 You can set it multiple times for multiple registries.
 
 #### --cleanup
@@ -391,7 +395,11 @@ This flag takes a single snapshot of the filesystem at the end of the build, so
 
 #### --skip-tls-verify
 
-Set this flag to skip TLS certificate validation when connecting to a registry. It is supposed to be used for testing purposes only and should not be used in production!
+Set this flag to skip TLS certificate validation when pushing to a registry. It is supposed to be used for testing purposes only and should not be used in production!
+
+#### --skip-tls-verify-pull
+
+Set this flag to skip TLS certificate validation when pulling from a registry. It is supposed to be used for testing purposes only and should not be used in production!
 
 #### --snapshotMode
 
@@ -467,12 +475,15 @@ filesystem is sufficiently complicated). However it has no `Dockerfile`-like
 build tooling (it's a slightly lower-level tool that can be used to build such
 builders -- such as `orca-build`).
 
-`Buildah` can run as a non root user and does not require privileges. Buildah
-specializes in building OCI images. Buildah's commands replicate all of the
-commands that are found in a Dockerfile. Its goal is also to provide a lower
-level coreutils interface to build images, allowing people to build containers
-without requiring a Dockerfile. The intent with Buildah is to allow other
-scripting languages to build container images, without requiring a daemon.
+`Buildah` specializes in building OCI images.  Buildah's commands replicate all
+of the commands that are found in a Dockerfile.  This allows building images
+with and without Dockerfiles while not requiring any root privileges.
+Buildah’s ultimate goal is to provide a lower-level coreutils interface to
+build images.  The flexibility of building images without Dockerfiles allows
+for the integration of other scripting languages into the build process.
+Buildah follows a simple fork-exec model and does not run as a daemon
+but it is based on a comprehensive API in golang, which can be vendored
+into other tools.
 
 `FTL` and `Bazel` aim to achieve the fastest possible creation of Docker images
 for a subset of images.  These can be thought of as a special-case "fast path"