Description
This is an outcome of #688, discussed and agreed with @mszostok. The solution is to use value field to store the rendered value, even for dynamic TypeInstances (the ones which has dynamic values fetched based on context).
AC
Reason
Previously, every downloaded TypeInstance in a workflow had a form of an artifact with the TypeInstance value.
Now, every TypeInstance have:
value: {} # static value, or resolved value based on context
backend:
context: {} # additional context for storage backend
Jinja2 templating and Artifact Merger already support unpacking value.
Sometimes the artifact could contain just the backend.context. For example, if we took an artifact prepared for Helm Template storage:
backend:
context:
chartLocation: https://charts.bitnami.com/bitnami
driver: secrets
name: postgresql-1648472938
namespace: default
value: null
The problem is that some of further workflow steps might need actual values, and the value is null.
Related issues
See #688
Description
This is an outcome of #688, discussed and agreed with @mszostok. The solution is to use
valuefield to store the rendered value, even for dynamic TypeInstances (the ones which has dynamic values fetched based on context).AC
Split gRPC API (resolved in Describe approach for dynamic TypeInstances in nested workflows and update gRPC API #696)
Dynamic and static Storage
Update code in backends and Hub
Add new gRPC method to the dynamic (context-only) Storage:
Update JSON schema for Storages (instead ofacceptValue, there will be an enum)Update Mattermost installation manifest and fully use Helm template backend for PostgreSQL (Use Helm template storage backend for PostgreSQL and Mattermost installation hub-manifests#66)
GetPreCreateValue) at the end of a given workflowModify TypeInstance uploader: TypeInstance upload would ignore TypeInstance value if a given Storage Backend (we have its ID) is dynamic (accepts only context)
Support GetPreCreate for Helm storage backends
Update documentation on website (resolved in Describe Storage Backend ProtoBuf API changes and TypeInstance Value Fetcher website#119)
Reason
Previously, every downloaded TypeInstance in a workflow had a form of an artifact with the TypeInstance value.
Now, every TypeInstance have:
Jinja2 templating and Artifact Merger already support unpacking
value.Sometimes the artifact could contain just the
backend.context. For example, if we took an artifact prepared for Helm Template storage:The problem is that some of further workflow steps might need actual values, and the
valueis null.Related issues
See #688