Pass parameters to your deployment

Using Cloud Deploy, you can pass parameters for your release, and those values are provided to the manifest or manifests before those manifests are applied to their respective targets. This substitution is done after manifests are rendered, as the final step in the Cloud Deploy render operation. Values are provided to all manifests identified in your skaffold.yaml file that contain the corresponding placeholders.

All you need to do is include placeholders in your manifest, and set the values for those placeholder in either your Cloud Deploy delivery pipeline or target configuration, or when you create a release.

This article describes how to make that happen.

Why use deploy parameters?

A typical use for this would be to apply different values to manifests for different targets in a parallel deployment. But you can use deploy parameters for anything that requires post-render key-value pair substitution in your manifest.

How it works

The following steps describe the general process for configuring deploy parameters and providing values:

1. You configure deploy parameterization, as described here.

   This includes the following:

   • Add the placeholders to your manifest, including a default value for each.

   • Add values for those placeholders.

     There are three ways to do this, described here.

2. When you create a release, your manifest is rendered.

   If you start with a templated manifest, values are applied now for template variables. If you start with a raw manifest, it remains unchanged. This rendering is done by Skaffold.

   However, you can have additional variables in your manifest for which values aren't applied at render time. These are the deploy parameters described in this document.

   At release creation, all deploy parameters are compiled into a dictionary, which is used to substitute values before the manifests are applied.

3. After rendering, Cloud Deploy substitutes values for deploy parameters.

   These are the values you configured in the first step.

   The rendering process already applied values to manifest templates, replacing some values, and adding labels specific to Cloud Deploy. But the values for these deploy parameters are substituted after rendering. The differences between manifest templates and deploy parameters are described here.

4. The manifest is applied to the target runtime, to deploy your application.

   This includes the values substituted at render time, and the values for any deploy parameters

Different ways to pass values

You can provide parameters, and values for those parameters in three ways:

• In the delivery pipeline definition

  You provide the parameter and its value in the definition for a stage in the delivery pipeline progression. The parameter is passed to the target represented by that stage. If that stage references a multi-target, the values set here are used for all child targets.

  This method lets you replace a value for all releases within a given pipeline, for all affected targets. The parameters defined for a stage identify a label, and the corresponding target for that stage must have a matching label.

• In the target definition

  You configure the parameter and its value in the definition for the target itself. This method lets you replace a value for that target for all releases.

• On the command line, when you create a release

  You include the parameter and its value using the --deploy-parameters flag on the gcloud deploy releases create command.

  This method lets you replace a value at release creation time, applying that value to that manifests of all affected targets.

Configuration for these is explained in more detail here.

Can I use more than one of these methods?

Yes, you can include deploy parameters in the pipeline stage, in the target config, and on the command line. The result is that all the parameters are accepted and added to the dictionary. However, if a specific parameter is passed in more than one place, but with different values, the gcloud deploy releases create command fails with an error.

How is this different from manifest templates

Deploy parameters, as described in this article, are distinguished from placeholders in a templated manifest by the syntax. But if you're wondering why you would need deploy parameters instead of just using the standard techniques for templated manifests, the following table shows the different purposes:

This document is about deploy parameters only (on command line, pipeline, and target), not templated manifests.

Limitations

• For each type of parameter, you can create a maximum of 50 parameters.