Problem
Humanitec services quite often use self-references in values substitution patterns.
For example ${modules.my-service.service.name}
.
At present there is no proper way to express self-references in Score spec.
Proposed Solution 1
Add support for self-references in form of ${workload.name}
.
Full set of available workload properties in to be discussed.
Proposed Solution 2
Introduce a notion of context
that then could resolve different properties based on CLI implementation.
For example it could be ${context.service.name}
.
Disadvantage is that it seems very confusing to the User where this context comes from.
Score file translated long before the deployment takes place, so any useful (dynamic) information, such as target environment name, is not available at this stage.
Proposed Solution 3
Reference any information available in metadata
section: ${metadata.name}
.
This could be useful for other properties and labels added into metadata
section in the future too.
Possible Workaround 1
The value pattern can be escaped in sore spec. E.g. $${modules.service-name.service.name}
.
While this would result in a valid value reference for Humanitec, e.g. ${modules.service-name.service.name}
.
It would make no sense for other target platforms (Compose or Helm).
Possible Workaround 2
It is possible to declare a resource (of type: workload
) with the same name as the workload itself, e.g. my-service
.
score-humanitec
could then convert resources references, such as ${resources.service-name.service.name}
into proper values references, e.g. ${modules.service-name.property}
.
However this would not work on other platforms. For example score-compose
would create a dependency on my-service
(self) which is an invalid circular dependency reference.