Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for erb statements within deployment manifests? #282

Closed
MatthiasWinzeler opened this issue Jul 31, 2017 · 2 comments
Closed

Support for erb statements within deployment manifests? #282

MatthiasWinzeler opened this issue Jul 31, 2017 · 2 comments

Comments

@MatthiasWinzeler
Copy link

With the ruby cli, it was possible to embed ERB statements in deployment manifest that were executed when deploying.

Example: https://github.com/pivotal-cf/cf-rabbitmq-release/blob/v229.2.0/docs/bosh_rabbitmq.md#unclustered-rabbit-with-customised-configuration

Currently, the new golang cli does not execute ERB code in deployment manifest which makes constructs as the one above impossible. Are there any plans to support this?

@dpb587-pivotal
Copy link
Contributor

That particular behavior was intentionally removed from the new CLI. We wanted to avoid the extra-dynamic ruby behavior in favor of a more declarative syntax. We also didn't want to be encouraging release authors to be distributing manifests where ruby/erb was a dependency.

We're not bringing back ERB support into the CLI commands, so now we're recommending the usage of ops files. The combination of variables and YAML manipulations can hopefully provide you with sufficient functionality for the use cases you need.

If you have any questions on those ops files, or have scenarios where they don't appear to work for your needs, please feel free to bring them up here or in slack so we can figure out recommendations/improvements we can make.

@MatthiasWinzeler
Copy link
Author

Thank you @dpb587-pivotal for your explanation.
That sounds reasonable to me. I don't see a lot of cases where one would really rely on this behavior so I guess this can be fixed in the respective releases rather easily. Will bring it up with them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants