For any source-based supply chains, that is supply chains that are not taking a pre-built image, when you specify the new
dockerfile parameter in a Workload the builds switch from using Kpack to using Kaniko. Kaniko is an open-source tool for building container images from a Dockerfile even without privileged root access.
||relative path to the Dockerfile file in the build context||
||relative path to the directory where the build context is||
||list of flags to pass directly to Kaniko (such as providing arguments, and so on to a build)||
For example, assuming that you want to build a container image our of a repository named
github.com/foo/bar whose Dockerfile resides in the root of that repository, you can switch from using Kpack to building from that dockerfile by passing the
$ tanzu apps workload create foo \ --git-repo https://github.com/foo/bar \ --git-branch dev \ --param dockerfile=./Dockerfile Create workload: 1 + |--- 2 + |apiVersion: carto.run/v1alpha1 3 + |kind: Workload 4 + |metadata: 5 + | name: foo 6 + | namespace: default 7 + |spec: 8 + | params: 9 + | - name: dockerfile 10 + | value: ./Dockerfile 11 + | source: 12 + | git: 13 + | ref: 14 + | branch: dev 15 + | url: https://github.com/foo/bar
Similarly, if the context to be used for the build must be set to a different directory within the repository, you can make use of the
docker_build_context to change that:
$ tanzu apps workload create foo \ --git-repo https://github.com/foo/bar \ --git-branch dev \ --param dockerfile=MyDockerfile \ --param docker_build_context=./src
Note: this feature has no platform operator configurations to be passed through
tap-values.yaml, but if
shared.ca_cert_datais configured in
tap-values, the certificates are considered when pushing the container image.