Configure Code Generation
At this point the Terraform modules have been connected, the module variables have been defined, the module dependencies have been connected, and the user experience has been defined. It is now time to add the blueprint resource, define the files to be generated, and configure the git destination for the generated code to be submitted.
The autocloud_blueprint resource ties all the assets together to create the consumer user experience. The first step is to define the resource and the metadata associated with the Terraform blueprint. Add the resource block below to the end of main.tf:
This resource now has a short display name (name) to identify the pattern in the catalog, along with the blueprint author, helper text describing what the blueprint does, and instructions to show the consumer when they deploy the pattern. The instructions block supports plain text as well as standard markdown. A set of labels are given to filter by, in this case identifying the cloud provider this blueprint targets.
Finally, the blueprint configuration defined in the previous steps is passed to the blueprint to define the user experience.
With all the contents and user experience defined, the generated code needs to be sent somewhere.
The AutoCloud Terraform blueprint generates code, and that code must live in files somewhere. The filenames are defined using file blocks. Add the following block to the autocloud_blueprint resource:
The file definition block consists of four elements. The action should currently always be CREATE, though future actions may be defined.
The destination argument defines the full file path and name relative to the git repository root for the file being generated. This filename may be dynamically populated using template interpolation. Similar to Jinja template syntax, a string variable stringvar may be defined in the variables block, whose value is substituted in the filename using the slug {{stringvar}}. The variables may reference module variable values using dot notation. Note that the module is referenced by the name attribute of the autocloud_module resource (cpkmskey), and not Terraform resource name (kms_key). In this example, our code is organized by environment, and all assets generated by this blueprint will be stored in a single file that corresponds to the full name of the resources generated.
The modules argument is a list of the generated module blocks to put in the file. Note that the modules are referenced by the Terraform resource name of the autocloud_module resource (kms_key), and not the name attribute (cpkmskey).
As many file blocks as desired can be added to accommodate your organization's Terraform code repository structure.
Now that the blueprint is defined and the files for the generated code are configured, the git submission behavior must be set. A pull request must be generated and sent to a destination git repository to be reviewed and deployed.
Filter the git repositories connected to AutoCloud to give the consumer the choice of destination for their generated code. Add a local variable to main.tf to filter the repositories based on URL:
The content for the pull request submitted to git is provided to the autocloud_blueprint resource as a string, and any suitable source may be used. For this example, the content will be sourced from a file stored with the Terraform source code. Create a directory to store template files and add an empty pull request template:
Add the pull request template content to this file:
Now that the destination repository and the pull request content are configured, define the git destination in the autocloud_blueprint resource. Add the following block to the resource definition:
The configuration options should be intuitive for those familiar with git. All strings in the pull_request block may be dynamically populated with template interpolation. Similar to Jinja template syntax, a string variable stringvar may be defined in the variables block, whose value is substituted in pull request elements using the slug {{stringvar}}. The variables may reference module variable values using dot notation. Note that the module is referenced by the name attribute of the autocloud_module resource (cpkmskey), and not Terraform resource name (kms_key).
The AutoCloud blueprint code generation configuration is now complete. The autocloud_blueprint resource should look like this:

