When during porter install are {{}} replaced with values? and are those replacements written to porter.yaml?

[karchf]

The issue: We have a ton of containers being moved with a cnab thick bundle. We can't go native helm mixin, because our deployment has some required waits and some logical changes, so we do quite a few helm installs with a powershell script which also handles the waits and the logic. Instead of passing a literal bajillion of repo and digest variables to powershell, we would like to be able to pass the porter.yaml file as a value file to the helm installs and pick up the rewritten {{}} from that file.

When i took a look at that file in the installer container those references haven't been rewritten yet. As such, when is the container wiring accomplished...and is there a yaml file that we can point to that has the rewiring done at install time?

[carolynvs]

Oh yes I see the problem. Template variables are replaced only for the current step just before the step is executed, and the resulting yaml is passed to the mixin responsible for executing the step. We do this because the step may rely upon values that created in the previous step, for example if you were using {{bundle.outputs.SOME_OUTPUT}} that isn't available at the beginning of install.

Here are some ideas for workarounds, and we are open to suggestions for altering porter if we have a clear use case.

• Parameters are available as environment variables that you can access directly. For example a parameter named my-param by default is available as $env:MY_PARAM in powershell.

• Image references (the mapping of image locations on one side of an airgap and its new location on the other side) are stored located in /cnab/app/relocation-mapping.json

  Here is the format of that file:

  {
      "myorg/mybundle@sha256:SOURCE_DIGEST": "altregistry/myorg/mybundle@sha256:SOURCE_DIGEST"
  }

• custom mixins are given the fully rendered step yaml

I think making a custom mixin may be too much in your case, but it would help to know the source of the template variables that you are interested in?

If all the info that you need is in the image references, Porter could easily provide that data in a better format for use in scripts. For example, rendering the final images section of porter.yaml to disk into a yaml or json file using the same format that is in the porter.yaml.

I'd love to help make this work better for you, so let me know if any of these sound useful and we can discuss further.