It fails on my side, using simple examples (tried with a simple docker.#Run and the local todoapp example).

Output:

$ dagger up -l debug
3:35PM DBG detected buildkit config    haveHostNetwork=true isActive=true version=v0.9.1                            
3:35PM DBG spawning buildkit job    attrs=null localdirs={
    "/Users/shad/forks/examples/todoapp": "/Users/shad/forks/examples/todoapp"
}
[✗] app.source                                                                                                                                        0.0s
[✗] registry.run                                                                                                                                      0.0s
executing operation    do=load pipeline=registry.run                                                                                                  0.0s
executing operation    do=fetch-container pipeline=registry.run.#up[0].from                                                           
#3 load metadata for docker.io/library/alpine:3.13.5@sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f                              
#3 sha256:5d6a82e946db573ca6bdbabd1c5064ba954a82bf2630842e76bcc6df20c80987                                                                    
#3 ERROR: no match for platform in manifest sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f: not found                
------                                                                                                                                        
> @registry.run.#up[0].from@ load metadata for docker.io/library/alpine:3.13.5@sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8…
------                                                                                                                                        
3:35PM FTL failed to up environment: task failed: no match for platform in manifest sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f: not found

Hardware: Macbook M1 (arch64) with docker for mac.

I guess the host arch is given implicitly and we hardcode sha256 of images that are x86, hence the hiccup. I think we may either default to x86 or have multi-arch sha256 in base packages.

You are right, we are hardcoding the alpine image package

// Default Alpine version
let defaultVersion = "3.13.5@sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f"

According to the manifest list, our defaultVersion is multi-arch compliant

docker buildx imagetools inspect docker.io/alpine:3.13.5@sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f
Name:      docker.io/library/alpine:3.13.5@sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f
MediaType: application/vnd.docker.distribution.manifest.list.v2+json
Digest:    sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f
           
Manifests: 
  Name:      docker.io/library/alpine:3.13.5@sha256:def822f9851ca422481ec6fee59a9966f12b351c62ccb9aca841526ffaa9f748
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/amd64
             
  Name:      docker.io/library/alpine:3.13.5@sha256:ea73ecf48cd45e250f65eb731dd35808175ae37d70cca5d41f9ef57210737f04
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/arm/v6
             
  Name:      docker.io/library/alpine:3.13.5@sha256:9663906b1c3bf891618ebcac857961531357525b25493ef717bca0f86f581ad6
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/arm/v7
             
  Name:      docker.io/library/alpine:3.13.5@sha256:8f18fae117ec6e5777cc62ba78cbb3be10a8a38639ccfb949521abd95c8301a4
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/arm64/v8
             
  Name:      docker.io/library/alpine:3.13.5@sha256:5de788243acadd50526e70868b86d12ad79f3793619719ae22e0d09e8c873a66
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/386
             
  Name:      docker.io/library/alpine:3.13.5@sha256:827525365ff718681b0688621e09912af49a17611701ee4d421ba50d57c13f7e
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/ppc64le
             
  Name:      docker.io/library/alpine:3.13.5@sha256:a090d7c93c8e9ab88946367500756c5f50cd660e09deb4c57494989c1f23fa5a
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/s390x

And I can run the pipeline with linux/arm64 architecture through a simple repro case.

@samalba Can you show me what is your architecture in the values.yaml? Because it should work according to the manifest.

The only issue in my opinion is that there is no architecture available for the mac m1?

✔️ Deploy Preview for devel-docs-dagger-io ready!

🔨 Explore the source changes: 0839cfd

🔍 Inspect the deploy log: https://app.netlify.com/sites/devel-docs-dagger-io/deploys/617ab10ab542e5000833d4c5

😎 Browse the preview: https://deploy-preview-1074--devel-docs-dagger-io.netlify.app

@aluzzardi @samalba I changed the architecture to linux/amd64 by default but I'm not sure Sam's issue comes from this.
Anyway, it's now possible to configure the pipeline architecture 🚀

@samalba Can you try one more time?

It works for new envs (I see the default architecture now being "linux/amd64" in the values.yaml), previously it was set to "darwin/arm64/v8" so this is an improvement.

However it breaks existing envs, the one without the "architecture" key in the values.yaml. I would also force the architecture to "linux/amd64" when there is no "architecture" key in the values.yaml (backward compatible).

After that last change, we should be good to go.

However it breaks existing envs, the one without the "architecture" key in the values.yaml. I would also force the architecture to "linux/amd64" when there is no "architecture" key in the values.yaml (backward compatible).

I suggest by default we don't put architecture in the values.yaml file (e.g. if the user doesn't specifically provide one) and use linux/amd64 as default in the runtime when values.yaml doesn't contain an architecture.

That way we are backward compatible. It's also possible to switch to auto-detection in the future if we want to. But if we write the hardcoded value in the values.yaml, we're stuck with it forever.

And beside that, this is ready to be merged.

It works for new envs (I see the default architecture now being "linux/amd64" in the values.yaml), previously it was set to "darwin/arm64/v8" so this is an improvement.

However it breaks existing envs, the one without the "architecture" key in the values.yaml. I would also force the architecture to "linux/amd64" when there is no "architecture" key in the values.yaml (backward compatible).

After that last change, we should be good to go.

Okay so I think I've understood why it failed on your computer, it's just because darwin/arm64/v8 is different than linux/arm64.
I think we could fix that in a new PR

alright, I confirm it works now with the last commit. LGTM.

Sorry, I did another test and it seems that the push is broken now.

I'll file an issue to make sure we address it before the next release: