tools: Expose ref-engine discovery casEngines #39
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the ref-engine we're checking returns no results, keep going (even if it didn't return an error). Also document the "ref-engine knows it doesn't have that name" results in the Engine.Get interface.
Previously these were not provided in the output JSON. To store the data during resolution, create a new resolvedName type. That type extends the usual MerkleRoot JSON with a new 'casEngines' property that is a sibling of MerkleRoot's 'root' and 'uri' properties. To get the sibling serialization, we need a little MarshalJSON wrapper for resolvedName, but we don't need to bother with UnmarshalJSON because this isn't a public library type. Rename 'allRoots' to 'resolvedNames', because each key in the map is an image name. Each value in the map may contain several roots (resolveNames), so 'allRoots' wasn't particularly clear. Move refenginediscovery.ResolvedCASEngine to engine.Reference. This gives us a shorter name, and lets us recycle some code via the new (private) (*Config).unmarshalInterface. That lets us get the same config serialization in Reference without the wash through bytes that I use in resolvedName.MarshalJSON. Washing through bytes is an acceptable hack for command-line-specific code, but it's nice to avoid it in the library code. While we're at it, clean up the MerkleRoot JSON handling, dropping the tag from MediaType (redundant because our JSON helpers don't use reflection) and adding comments for the public methods. Alphabetizing the root entries in the oci-discovery README example probably should have happened back in bb96e49 (tools/refenginediscovery: Refactor Ref-Engine Discovery library API, 2017-09-20, xiekeyang#29), since that's when we started using a map[string]interface{} in MerkleRoot.MarshalJSON.
wking
force-pushed
the
go-expose-ref-engine-discovery-casEngines
branch
from
585f61f to
c0c2e99
Compare
Owner
|
LGTM |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously these were not provided in the output JSON.
To store the data during resolution, create a new
resolvedNametype. That type extends the usualMerkleRootJSON with a newcasEnginesproperty that is a sibling ofMerkleRoot'srootanduriproperties. To get the sibling serialization, we need a littleMarshalJSONwrapper forresolvedName, but we don't need to bother withUnmarshalJSONbecause this isn't a public library type.Rename
allRootstoresolvedNames, because each key in the map is an image name. Each value in the map may contain several roots (resolveNames), soallRootswasn't particularly clear.Move
refenginediscovery.ResolvedCASEnginetoengine.Reference. This gives us a shorter name, and lets us recycle some code via the new (private)(*Config).unmarshalInterface. That lets us get the same config serialization inReferencewithout the wash through[]bytethat I use inresolvedName.MarshalJSON. Washing through[]byteis an acceptable hack for command-line-specific code, but it's nice to avoid it in the library code.While we're at it, clean up the
MerkleRootJSON handling, dropping the tag fromMediaType(redundant because our JSON helpers don't use reflection) and adding comments for the public methods.Alphabetizing the root entries in the oci-discovery README example probably should have happened back in #29, since that's when we started using a
map[string]interface{}inMerkleRoot.MarshalJSON.Builds on #38; review that first.