We need to be able to incorporate manual modifications to the extracted example manifests (and potentially to other metadata elements such as extracted field docs, etc.).
We already have a resource configuration framework in upjet, the config.Resource, which we would like to utilize also for metadata customizations.
For example, for manual customizations involving extracted example manifests, some anticipated use cases are:
- Fixing syntax errors in the scraped examples from the Terraform registry
- Adding/removing attributes, if desired, to/from the extracted example manifest
- Adding/fixing/removing cross-resource references
- Marking resources that require globally unique names, such as the Azure Key Vaults or AWS S3 buckets.
- ...
We can use crossplane-runtime's fieldpath library and represent the example manifests with paved objects with field addressing semantics and field manipulation routines. This would also allow us to introduce repo-wide customizations, such as injecting a specific field (such as a region field) into all generated example manifests for a provider.
We need to be able to incorporate manual modifications to the extracted example manifests (and potentially to other metadata elements such as extracted field docs, etc.).
We already have a resource configuration framework in upjet, the config.Resource, which we would like to utilize also for metadata customizations.
For example, for manual customizations involving extracted example manifests, some anticipated use cases are:
We can use crossplane-runtime's fieldpath library and represent the example manifests with paved objects with field addressing semantics and field manipulation routines. This would also allow us to introduce repo-wide customizations, such as injecting a specific field (such as a
regionfield) into all generated example manifests for a provider.