Is it possible to (re)publish an image without changing it's digest?

[inland rose]

Hello! I'm looking for an operation which let's me do something like

func (m Mod) Promote(ctx context.Context, imageRef string) (string, error) {
  // 1. Take an image reference as an input
  // 2. Publish under a different tag in an image repository, without creating a new manifest
  //
  // Something like
  return dag.Container().From(imageRef).Publish(ctx, "registry/repo:staging")
}

Called like

dagger call promote --image-ref registry/repo@sha256:{digest}

What I'm finding is that the simple approach always creates a new manifest when the referenced image is not already cached. Is there a recommended approach to only update the registry/repo tag without defaulting to external tool like skopeo ?

[stone zodiac]

@inland rose is this the symptom, you publish and get one digest, then publish same image again and get a different digest, which is then consistent after that...

[inland rose]

@stone zodiac Ah, yes, thank you! I think this demonstrates the symptom well.

[stone zodiac]

@vital mortar seen this before? First digest of a container | publish not settled, then seemingly settled and immutable thereafter?

[vital mortar]

Can look in more detail later, but I have a feeling it probably has to do with multiplatform images. Container().From("alpine") automatically resolves the image to your platform and then when you publish it you publish just that platform, which is different than publishing a multiplatform image (https://docs.dagger.io/cookbook/#build-multi-arch-image)

If that's it, that's indeed a pretty big gotcha, would need to think about how to make it work more intuitively

[stone zodiac]

got it.
I did with ubuntu and saved the docker inspect output of the two diff digests as v1 and v2.

docker inspect localhost:5000/ubuntu > v1
...
docker inspect localhost:5000/ubuntu > v2
diff v1 v2

no difference

Will look at multiplatform

no diff in tarballs either

~ ➤ docker save localhost:5000/ubuntu > debian-v2.tar
~ ➤ docker inspect localhost:5000/ubuntu > debian-inspect-v2
~ ➤ diff debian-inspect-v1 debian-inspect-v2
~ ➤ diff debian-v1.tar debian-v2.tar

[inland rose]

Just following up on this. I do find the above nuanced publish behaviour inconsistent and a bit confusing while testing/experimenting. Another goal I had in mind was finding out how I could copy and image rather than publish it, ensuring something like (from fresh, no cache) would result in an identical digest when published:

dagger shell -c 'container | from alpine@sha256:a8560b36e8b8210634f77d9f7f9efd7ffa463e380b75e2e74aff4511df3ef88c | publish localhost:5000/test'
localhost:5000/test@sha256:ac5b65813865592e25d308561d903fea8eeed8181365fc536f244610e9ffd710

However, the pulled digest and published digests differ here. From what I can tell, the only difference between the manifests are the timestamps (see discussion topic? Maybe I was thinking more along the line's of skopeo copy with the --preserve-digests flag.

--preserve-digests
Preserve the digests during copying. Fail if the digest cannot be preserved.

[inland rose]

@stone zodiac @vital mortar would there be interest in exposing something like buildkit's exptypes.OptKeyRewriteTimestamp field during container publish?

[inland rose]

^ Would exposing something like this option allow the possibility of an image's manifest not changing when (re-)pushed to a registry (similar to skopeo-copy)?

[drifting flame]

What you want might be https://github.com/dagger/dagger/issues/7721