Open phlummox opened 3 years ago
I created a sample of this on play.spruce.cf, with tracing enabled. it seems like spruce isn't recognizing that some_text
is an operator.
DEBUG> running (( grab ... )) operation at $.ingredients.3.bits_of_text
DEBUG> arg[0]: trying to resolve reference $.some_text
DEBUG> [0]: resolved to a value (could be a map, a list or a scalar);
→ appending
Looks like https://github.com/geofffranks/spruce/commit/265eb84025080b2e32ccfc5bee387465c3fe6b62 solved this slightly. Older versions didn't resolve any operators. That resolved one level. Need to make it more recursive so any dependencies are pulled in.
Feel free to PR for this if you want @phlummox!
I'm afraid I don't know Go, so I don't think there's anything I'd be able to usefully provide in a PR. Best of luck resolving the issue.
According to the merging rules, cherry-picking should happen as the last-but-one stage of merging. And "--cherry-pick" and "--prune" are described in the command --help as opposites of each other. However, they seem to give very different results in the following case, and whether cherry-picking is done seems to alter the behaviour of earlier stages.
Assume we have the following files:
recipe.yaml:
text.yaml:
and lorem.txt:
If we run
then we get the expected output:
But if we instead try and cherry-pick the "name", "method" and "ingredients" keys, we get quite different output, and the "
file
" operator in text.yml doesn't seem to have been executed at all. Executinggives the output:
So something seems to be wrong - either the documentation isn't correct that "cherry-pick" happens at the penultimate stage, or the merge isn't being done according to the semantics given. (Or I'm encountering some sort of undefined behaviour due to misuse of the operators, but if so, that's not obvious to me.)
I'm using version 1.28.0 of spruce, downloaded from https://github.com/geofffranks/spruce/releases/download/v1.28.0/spruce-linux-amd64.