feat: support custom placeholder delimiters via workload annotations#501
feat: support custom placeholder delimiters via workload annotations#501Abhishek9639 wants to merge 1 commit into
Conversation
…core-compose Signed-off-by: Abhishek <abhishekup082@gmail.com>
a74e7ae to
3f60ddf
Compare
|
Hey @chris-stephenson, @mathieu-benoit, opening this for review. This is the score-compose-only implementation of score-spec/spec#108, following what we agreed at the meeting. score-go is intentionally untouched: the substitution is done by a small unexported helper inside The behaviour matches what was in the closed score-go PR (score-spec/score-go#188) two annotations ( If this works out in practice, we can revisit a proper score-go API later. Could one of you approve the workflows so CI can run? First PR from me on this fork too. |
Description
Adds opt-in support for custom placeholder delimiters in file content expansion, via two workload-level annotations under the existing
compose.score.dev/experiment-*namespace. This is the experimental implementation of score-spec/spec#108. score-go is intentionally untouched, so the experiment lives entirely insideinternal/composeand is cheap to walk away from if it doesn't pan out. That direction was agreed at the community meeting with @chris-stephenson.What does this PR do?
Two new annotations:
compose.score.dev/experiment-placeholder-startcompose.score.dev/experiment-placeholder-endWhen both are set on a workload, file content is expanded using the given delimiter pair instead of the default
${...}syntax. Both are required together. Setting only one of them, or leaving either value empty, produces a clear error up front.noExpand: trueon a file still takes priority, andbinaryContentis never expanded.The substitution is done by a small unexported helper,
substituteWithDelimiters, that builds a regex fromregexp.QuoteMeta(start) + "(.*?)" + regexp.QuoteMeta(end)and runsReplaceAllStringFunc. No escape mechanism in this version. Reasoning is on the parent issue: a doubled-prefix escape doesn't extend cleanly to asymmetric pairs like<</>>or<%{/}%>, and a backslash escape was set aside until someone hits the problem in practice.Example use case (Spring Boot properties, where literal
${...}needs to survive so Spring can resolve it at runtime):Tests added for: annotation set with
%{ }, asymmetric delimiters<%{ }%>, unset/default behaviour,noExpandpriority, only-start error, only-end error, empty-value error.examples/03-files/README.mdhas a new section documenting the annotations.Refs: score-spec/spec#108
Types of changes
Checklist