Ben Meier

We've just hit exactly the same issue here. According to HTTP 1.1 spec documents: ``` Because of the presence of older implementations, the protocol allows ambiguous situations in which a...

The score implementations currently support both metadata references for `${metadata.name}` or `${metadata.thing.key}` and also support escaped runtime references such as `$${modules.other-service.service.name}` which get unescaped before injection into the target system....

This needs to be moved to the respective Score implementation CLIs if needed. Closing as stale.

I'm going to close this and suggest that this is down to individual implementations to implement as they choose. Feel free to continue with the score-compose specific PR. 👍

I'm going to close this PR since #166 seems like a better approach :)

Check the `~/.surepy.token` file, it looks like it is successfully exchanging the creds for a bearer token and writing it to that file, but the cli just doesn't log a...

@mathieu-benoit which Score implementation was this for? It looks like this is from Humanitec and you'll need to raise this with their support.

@garthy thanks for filing the request. Currently secret outputs from resources being injected into envvars and file mounts are handled by the Score implementations themselves. Eg: score-k8s will expect the...

Just looking at the output quickly I can see the manifest looks like ``` $ go run github.com/score-spec/score-helm/cmd/score-helm@latest run score.yaml go: downloading github.com/score-spec/score-helm v0.0.0-20240105083034-d29b2dfdefe6 go: downloading github.com/score-spec/score-go v0.0.0-20230905115428-131acdd2f5cf containers: backend:...

Unfortunately @bobbydeveaux this is expected behavior, Score is a workload spec and generates 2 containers in the same pod (the same workload). If you're looking for 2 services (backed by...