github.com/GoogleContainerTools/skaffold/v2@v2.13.2/docs-v2/content/en/docs/renderers/kpt.md (about)

     1  ---
     2  title: "Kpt [NEW]"
     3  linkTitle: "Kpt [NEW]"
     4  weight: 30
     5  featureId: render
     6  aliases: [/docs/pipeline-stages/renderers/kpt]
     7  ---
     8  
     9  {{< alert title="Note" >}}
    10  kpt CLI must be installed on your machine for the below functionality. Skaffold will not
    11  install it.
    12  {{< /alert >}}
    13  
    14  ## `manifests.transform` and `manifests.validate` functionality powered by kpt
    15  With Skaffold V2, skaffold now has a new `render` phase and associated `manifests` top level config field.   Along with these changes,  a `manifests.transform` and a `manifests.validate` field were added which allows users to specify `kpt` manifest transformations and validations to be done in the `render` phase.  `manifests.transform` allows users to create a pipeline of manifest transformations which transform manifests via the specified container.  For more information on the `manifests.transform` functionality see, the docs for `kpt` `mutators` [here](https://kpt.dev/book/04-using-functions/01-declarative-function-execution).  For a list of `kpt` supported containers to use in the `manifests.transform` schema see the list [here](https://catalog.kpt.dev/) with the tag `mutator`.  `manifests.validate` allows users to create a pipeline of manifest validations that run serially, checking the yaml manifests for the specified validation test.  For more information on the `manifests.validate` functionality, see the docs for `kpt` `validators` [here](https://kpt.dev/book/04-using-functions/01-declarative-function-execution).  For a list of `kpt` supported containers to use in the `manifests.validate` schema see the list [here](https://catalog.kpt.dev/) with the tag `validator`.
    16  
    17  Conceptually these top level fields remove the necessity of a separate Kptfile allowing more users to adopt the powerful rendering functionality `kpt` enables.  Functionally, these fields are identical to having a seperate `Kptfile` with the `manifests.transform` -> `pipeline.mutators` and `manifests.validate` -> `pipeline.validators`.
    18  
    19  An example showing how these fields can be used is below.  Run `skaffold render` in a directory with the following files:
    20  
    21  `skaffold.yaml`
    22  {{% readfile file="samples/renderers/kpt-manifest-fields.yaml" %}}
    23  
    24  
    25  `kpt-k8s-pod.yaml`
    26  ```yaml
    27  apiVersion: v1
    28  kind: Pod
    29  metadata:
    30    name: getting-started
    31    app: guestbook
    32  spec:
    33    containers:
    34    - name: getting-started
    35      image: nginx
    36  ```
    37  
    38  The aboveconfiguration above adds a field `metadata.annotations.author` with value `fake-author`, adds a `kpt` "setter" comment (` # kpt-set: ${app}`) to the intermediate yaml, modifies the value at the location of the `kpt` "setter" field with the provided `app` value (`app: guestbook-fake-author`) and then validates that the yaml is valid yaml via `kubeval`.
    39  
    40  
    41  ## Rendering with kpt using a Kptfile
    42  
    43  [`kpt`](https://kpt.dev/) allows Kubernetes
    44  developers to customize raw, template-free YAML files for multiple purposes.
    45  Skaffold can work with `kpt` by calling its command-line interface.
    46  
    47  
    48  ### Configuration
    49  
    50  To use kpt with Skaffold, add render type `kpt` to the `manifests`
    51  section of `skaffold.yaml`.
    52  
    53  The `kpt` configuration accepts a list of paths to folders containing a Kptfile.
    54  
    55  ### Example
    56  
    57  The following `manifests` section instructs Skaffold to render
    58  artifacts using kpt.  Each entry should point to a folder with a Kptfile.
    59  
    60  {{% readfile file="samples/renderers/kpt.yaml" %}}
    61