containerimage buildkit source shenanagins

[last nebula]

@maiden delta @fervent dome i'm attempting to get From working with Services by adding a containerimagedns bk source, i've written a small wrapper of the upstream bk source that injects search domains

with this wired in, any invocation to From ends up giving this very opaque bk error

    multi.go:85: 7   : ! failed to resolve image docker.io/library/alpine:3.20.2: ref mutated by policy to non-image: docker-image://docker.io/library/alpine:3.20.2 -> docker-image://docker.io/library/alpine:3.20.2

digging through bk code, it looks like this error occurs in various frontends when the image resolves to nil

wiring the upstream image source impl into source manager doesn't give this same error.

3 known unknowns i have about the other dns sources are:

1. what cache.Accessor is for, and if it's necessary
2. what purpose is served by state.go files in each source impl
3. why bk's baseWorker manages imageSources via field-literal *containerimage.Source instead of using SourceManager like the others

any hunches? would you dig on any of these things? this feels like it's either a typo i'm just not seeing or i'm missing some element of how sources work.

[maiden delta]

Yeah that's quite the error, taking a quick look I wouldn't be surprised if the problem lies here in buildkit code: https://github.com/sipsma/buildkit/blob/e15601a00fbef2805db1ed87be7bb88628ae926b/worker/base/worker.go#L392-L392

It's doing type assertions that I suspect won't work anymore now that we are returning types from our own package rather than upstream's. That code appears to just return nil Image in the case where none of the types matched, which would lead to the error you're getting (i.e. here https://github.com/sipsma/buildkit/blob/e15601a00fbef2805db1ed87be7bb88628ae926b/client/llb/sourceresolver/imageresolver.go#L54-L54)

We have our own worker though. We are currently inheriting that ResolveSourceMetadata method from buildkit's impl, but we can just put our own implementation of it here: https://github.com/sipsma/dagger/blob/8e9ea861512982df6e46ac01902ff0c158e5856a/engine/buildkit/worker.go#L144-L144

Which should fix that (if it's indeed the problem, just making educated guesses so far)

[last nebula]

sick tq, i will give that a shot. didn't even realize there was a worker interface to play with here

[last nebula]

containerimage buildkit source shenanagins

[last nebula]

@maiden delta that made me some significant progress, now i'm in a crazy sequence of cribbing pieces out of llb, basically trying to make a containerimagedns/state.go to wire into core/container.go. i think i've hit a wall because llb ImageInfo has all its fields private unlike the rest of the *Info structs in there.... again uncertain how to proceed, i suspect it's not feasible to swap that particular struct out with our own implementation, should i try to change it upstream? feels like it might be a breaking change to capitalize all these ... the alternative is to keep expanding our shadow-llm copy beyond just the Image function, but continuing to pull that thread at 4pm has me suspicious im on the wrong track lol, thoughts?

[last nebula]

pulled further on the reimplementing imageinfo and it's pretty fraught... you end up having to copy the entire universe of llb Options and/or llb state

there's gotta be another way... has anybody tried to like post-process modify llb.State?

[maiden delta]

Did you see DefToDAG? https://github.com/sipsma/dagger/blob/c1ad6bd22db15212cb2e243949aef38e79caab4b/engine/buildkit/llbdefinition.go#L16-L16

You give it marshalled LLB and it unpacks it back into something you can modify, won't have to deal with any private fields or anything.