-
Notifications
You must be signed in to change notification settings - Fork 374
yq: failed traversing anchors in version.yaml #2430
Comments
The latest yq might not "resolve" the anchor, if it refers to an scalar (string, integer etc). But it's fine with the collections (sequences, mappings). Fixes: kata-containers#2430 Signed-off-by: Penny Zheng <penny.zheng@arm.com>
@Pennyzct also see kata-containers/tests#2275 |
For ref, some yq docs referring to the difference between fetching an anchor and resolving (following) an anchor ... https://mikefarah.gitbook.io/yq/commands/read#anchors-and-aliases |
I dug a fraction more (as this is something I don't know much about in yaml, and wanted to). I think the issue is when we have an anchor on something that has a value - I think that is called a 'scalar'?. So, with the yaml: ---
assets:
initrd:
architecture:
aarch64:
name: &default-initrd-name "alpine"
version: &default-initrd-version "3.7"
ppc64le:
name: *default-initrd-name
a2:
aarch64: &default-initrd
name: "alpine"
version: "3.7"
ppc64le: *default-initrd and the code: #!/bin/bash
set -x
yq2 read v2.yaml "assets.initrd.architecture.ppc64le.name"
yq3 read v2.yaml "assets.initrd.architecture.ppc64le.name"
yq2 read v2.yaml "assets.initrd.a2.ppc64le.name"
yq3 read v2.yaml "assets.initrd.a2.ppc64le.name" I get:
Looking around, I think what we have is valid YAML anchors - so, I suspect this is a yq issue. |
I've raised mikefarah/yq#340. |
Description of problem
Recently, initrd-related CI are failing frequently.
http://jenkins.katacontainers.io/job/kata-containers-runtime-ubuntu-18-04-PR-initrd/2843/
Debugging on the above output, the cause may come from that yq failed reading values from
assets.initrd.architecture.$arch.name
Based on the latest yq spec, the read command could print out the anchors of a document and can also traverse them.
But when anchor refers to an scalar (string, integer etc), the latest yq could not traverse it.
e.g.
The text was updated successfully, but these errors were encountered: