some code question about cacheMap

[vaneyli]

1: an edge's cacheMapReq will be called many times? why. edge.go:429
2: commitOptions() why an edge has many CacheKey when e.deps ==0
3:func (e *edge) execOp(ctx context.Context) (interface{}, error). why res := results[int(index)]?? just use a single result?
ops.exec.go:Exec will return many Results.

[vaneyli]

@tonistiigi please help me. thanks :)

[tonistiigi]

Ops can have many multiple cache keys. Eg. image can be cached both by root manifest digest and image config rootfs digest.

ExecOp can return multiple outputs. One for each readwrite mount. It is not possible in Dockerfile to refer back to other mounts but this is possible in LLB.

[vaneyli]

Thanks :) more detail questions:
1: Two edge belong to the same Op, such as the same ExecOp. But {Edge.Vertex = a , Edge.Index = 0} {Edge.Vertex = a , Edge.Index = 1} are two different edges which could be the input to other edges. The Results of ExecOp：Results[0] used by Edge.Index=0. and Results[1] used by Edge.Index=1. But the real ExecOp:exec() just run once by the flightcontrol which make sure the only one running. All the above is right ?

2: k := NewCacheKey(e.cacheMap.Digest, e.edge.Vertex.Digest(), e.edge.Index) the index will make the above two edges to produce different Cachekeys. Whether the two edge's cacheMap.Digest is the same one? But what's the meaning of edge.cacheMapDigests. (I see the sourceops may be get two different cachemap. Digest at func (p *puller) CacheKey)

thanks

[tonistiigi]

1. One vertex, op, container, process. Two edges, mounts, snapshots.
2. cacheMapDigests multiple items comes from multiple cache keys (algorithms) for a single specific op like explained earlier. Number of edges for the op/vertex does not matter in here.

The graph is solving for edges because the build result is a snapshot/rootfs. The build steps(eg. exec containers) are vertices. Definition for how a step is cached(cachemap) is provided by the op/vertex. The actual cache key/digest is to lookup/save snapshots.

[vaneyli]

1:
//solver/cache_test.go
func testCacheKey(dgst digest.Digest, output Index, deps ...ExportableCacheKey) *CacheKey {
k := NewCacheKey(dgst, "", output)
k.deps = make([][]CacheKeyWithSelector, len(deps))
for i, dep := range deps {
k.deps[i] = depKeys(dep)
}
return k
}

k := testCacheKey(dgst("baz"), Index(1), *cacheFoo, *cacheBar)
keys, err = m.Query(depKeys(*cacheFoo), 0, dgst("baz"), Index(1))

k1: = testCacheKey(dgst("baz"), Index(1), *cacheFoo)
keys2, err = m.Query(depKeys(*cacheFoo), 0, dgst("baz"), Index(1))

If keys[0].ID == keys2[0].ID ?

2: You are right , an ops（without deps） can be hit by many different cache keys which is hard to understand for the common DAG(other build system) just use one key to decide the cache hit. Thanks