Skip to content

Includable job to build container image

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

Add an includable job .build_with_kaniko to build a container image if the repository contains a Dockerfile.

Problem to solve

Currently, the recommended process for building a container image is to copy-paste from https://docs.gitlab.com/ee/ci/docker/using_kaniko.html.

This seems like a natural opportunity to use an includable, since the script will basically never need to be customized, except via variables which can be set.

As an example of an image to be built, consider https://gitlab.com/shell-bootstrap-scripts/tar-jq-image. This repository can be mirrored to any GitLab instance to build a small simple image with just a couple of utilities included.

Intended users

This is intended for use by anyone who wants to build container images.

User experience goal

The ideal user experience is for the user to include the job, commit their Dockerfile, and never worry about it again.

Unfortunately, some customization will probably be necessary; that's where variables come in.

If the Dockerfile is not named simply 'Dockerfile' (though it often is), the user may need to specify the path to the Dockerfile-equivalent file.

For consistency with that, in the existing https://gitlab.com/shell-bootstrap-scripts/tar-jq-image/-/blob/tar-jq-alpine/.gitlab-ci.yml#L12, the variable SKIP_DOCKER_TAG_COMMIT_SHORT_SHA is also used to prevent tagging the saved image with the git commit hash. (Following https://gitlab.com/guided-explorations/containers/kaniko-docker-build, built images are tagged with the hash by default.)

Proposal

The simplest method is probably to use a template analogous to https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Docker.gitlab-ci.yml.

We could even used a non-dotted job that will run on its own without being extended, like in https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Docker.gitlab-ci.yml, but it may be wiser to make the standard method-of-use be to extend a dotted job, so that variables can be overridden at will.

Currently, https://gitlab.com/shell-bootstrap-scripts/tar-jq-image/-/blob/tar-jq-alpine/.gitlab-ci.yml looks like this:

include:
- project: 'shell-bootstrap-scripts/shell-bootstrap-scripts'
  file: 'build_with_kaniko.yaml'
  ref: master

build_for_gitlab_project_registry:
  extends: .build_with_kaniko
  variables:
    SKIP_DOCKER_TAG_COMMIT_SHORT_SHA: 1
    # It is not necessary to set PATH_TO_DOCKERFILE here.
    # PATH_TO_DOCKERFILE is set here only as an example of how to use PATH_TO_DOCKERFILE.
    PATH_TO_DOCKERFILE: Dockerfile

Only the initial include would need to change.

Further details

Permissions and Security

Documentation

Availability & Testing

Available Tier

  • Free

Feature Usage Metrics

If implemented as a template, this can use the standard template usage tracking.

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited by 🤖 GitLab Bot 🤖