SETTINGS.md

Before you get started

Connect and configure these integrations:

1. GitHub (required)
2. Docker Hub Registry or Google Container Registry (required)

How to configure

1. Select a Docker registry to push to

   

   First connect at least one Docker registry from Manage -> Integrations. Once connected you can then select a registry to push to.

2. Select Docker registries to pull from

   

   Occasionally you may want to pull private base images from a different registry. Use the Docker registries to pull from parameter to configure those additional registries.

3. Map secrets to environment variables

   

   If your container needs access to secret values, e.g., authentication tokens or passwords, you can create a secret to store the value and then map that secret to an environment variable here. Select the secret from the drop down and then provide a name for the environment variable. The running container will then have the value of that secret available to it as the value of the environment variable.

   Note that by default container environment variables are not passed to the Docker build context. To make the environment variable available within the Docker build context you must declare it as an ARG in the Dockerfile and provide it as a --build-arg to kaniko. For example, assign the secret to the environment variable MY_TOKEN, then your Dockerfile should contain the line ARG MY_TOKEN prior to using $MY_TOKEN in the Dockerfile, and add the kaniko argument --build-arg=MY_TOKEN below.

4. Environment variables

   

   Specify any environment variables needed for your image and commands to run. The environment variable format is KEY=VALUE. For example: GIT_URL=https://github.com.

   As with the secret environment variables, container environment variables are not passed to the Docker build context. To make the environment variable available within the Docker build context you must declare it as an ARG in the Dockerfile and provide it as a --build-arg to kaniko. For example, set the environment variable PROFILE=production here, then your Dockerfile should contain the line ARG PROFILE prior to using $PROFILE in the Dockerfile, and add the kaniko argument --build-arg=PROFILE below.

5. Select the trigger for running this skill

   

   This skill can build Docker images on Git push or tag events. Use this parameter to configure the trigger.

6. Specify the name of the image

   

   Provide the name of the Docker image to create. If not provided this defaults to the name of repository.

7. Specify the tag to create

   

   Specify the Docker image tag to create. If not provided the default depends on how the build was triggered. If the build was triggered on a push, the default tag is the git SHA of the commit at the head of the push. If the build was triggered by a tag, the default tag is the name of the Git tag.

8. Specify the path to the Dockerfile

   

   Path to the Dockerfile to use for building the image. This defaults to ./Dockerfile.

   The path is relative to the root of the repository.

9. Extra kaniko arguments

   

   If your Docker build requires special arguments to kaniko, you can provide them here.

   You can use this option to pass environment variables through to the Docker build context.

   --build-arg=NODE_ENV
   

   You can use this option to create additional image tags. For example, to add the "latest" tag to all images created by builds triggered by a tag, you can add this kaniko argument:

   --destination=${data.Tag[0].commit.repo.owner}/${data.Tag[0].commit.repo.name}:latest
   

   Similarly, to add the "next" tag to all images created by builds triggered by a push of commits, you can add this kaniko argument:

   --destination=${data.Push[0].repo.owner}/${data.Push[0].repo.name}:next
   

   In both of the above examples, we use data from the event that triggered the Docker build to provide the image repository and name.

   Note that each argument provided is passed as a single argument to kaniko, no command-line parsing is done. This means that command-line options that take a value should either be provided as a single argument with the option and value joined by an equal sign (=), e.g., --context-sub-path=docker, or as two separate arguments, the first being the option and the second being the value, e.g., --context-sub-path and docker.

10. Create GitHub commit check (advanced)

    

    If selected, a GitHub check will be added to the commit indicating whether the build succeeded for failed.

11. Kaniko version (advanced)

    

    To use a specific version of the kaniko executor to build your Docker image, enter the Docker image tag of the version you want to use here, e.g., v1.3.0.

12. Kaniko caching (advanced)

    

    By default, kaniko is run such that it caches intermediate image layers during the build. Caching intermediate image layers can speed up subsequent builds. To disable image layer caching, uncheck this box.

13. Determine repository scope

    

    By default, this skill will be enabled for all repositories in all organizations you have connected.

    To restrict the organizations or specific repositories on which the skill will run, you can explicitly choose organizations and repositories.

14. Activate the skill

    Save your configuration and activate the skill by clicking the "Enable skill" button.