ops: merge go op-stack build into dockerfile targets

[protolambda]

Description

Previously we simplified the main Go op-stack components down to one shared docker build, and individual docker images per target.

To avoid the manual relation between separate Dockerfiles, we can use docker targets within a unified Dockerfile, and isolate the the build stage per docker target, while still sharing the same Go mod and build caches.

This is experimental: the hypothesis is that now that the Circle CI docker-layer-cache works, we don't have to manually specify the common relationship between the different targets. There may be some less overlap due to things running in parallel, but cache re-use across different pipelines should help handle most of the work.

We can watch the CI time / build results, and revert the PR later if it affects the CI time badly.

By doing this, we avoid the need for the explicit intermediate "op-stack-go" docker image, simplifying our CI and devnet setup.

Bonus: the version build-args are now set in the docker bake config, and default to the global GIT_VERSION bake var, which is set during the CI build. So when running docker run --rm -it us-docker.pkg.dev/oplabs-tools-artifacts/images/op-node:versionhere op-node --version it should print the correct version.

Metadata

Fix https://github.com/ethereum-optimism/client-pod/issues/238

[ajsutton]

Looking at CI build times it looks like this makes no difference to the total build time (still 25mins on this PR and on the latest develop build). However the docker build steps are way faster. op-node-build for example is 46s in this PR vs 1m34s for op-stack-docker-build plus 1m27s for op-node-docker-build in the last develop build. Maybe it hit caches better - I can see one build from develop that took 55s and 34s but it looks like the split approach is costing a bunch of time in saving artefacts and schlepping them between build jobs.

Haven't looked at the code changes yet but on those timings this seems like a win all round - simpler and faster.

[ajsutton]

Do we need to update the Makefile golang-docker target? It's passing for me but the built images don't work on Mac:

$ make golang-docker
#61 [op-challenger] exporting to image
#61 exporting layers done
#61 writing image sha256:8f22a06b949a369a792e419cc034f2b85becd02de29708464ce2b5b1cdee09d3 done
#61 naming to us-docker.pkg.dev/oplabs-tools-artifacts/images/op-challenger:4775de60371bb7d2844baa14549d0cc86c11f3df done
#61 naming to us-docker.pkg.dev/oplabs-tools-artifacts/images/op-challenger:latest done
#61 DONE 0.0s
 $ docker run us-docker.pkg.dev/oplabs-tools-artifacts/images/op-challenger:4775de60371bb7d2844baa14549d0cc86c11f3df
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/op-challenger: no such file or directory

I'm not sure why it built amd64 or why it couldn't find the op-challenger command. I've pruned all the existing docker images locally so it should have been a clean build.

The devnet does work on Mac and is building an arm64 image as expected.

[protolambda]

@ajsutton looks like I missed the --platform somewhere in the dockerfile, will investigate.

[protolambda]

@ajsutton turns out I didn't set the default target platform variable to the local build platform, so it was cross-building for amd64 while on arm. I made all the platform choices in the dockerfile explicit now to be sure, and fixed the plaform default, and tested it on a macbook air m2 (arm v8) running asahi linux. Should be good to go now.

[ajsutton]

I was just testing the latest commit you pushed locally and it was failing with:

ERROR: failed to solve: alpine:3.18: no match for platform in manifest sha256:eece025e432126ce23f223450a0326fbebde39cdf496a85d8c016293fc851978: not found

it passed when I set that default to linux/arm64 though so I wonder if the default I'm getting is something dumb like mac/arm64. Good to know it worked for you though - leave it with me and I'll have a play locally after office hours to see what's going on.

[ajsutton]

Yeah I'm getting:

      "platforms": [
        "darwin/arm64/v8"
      ],

Works if I set the PLATFORMS env var to linux/arm64. Not sure why we have different defaults yet but it's happening on both my work and personal Mac. I do tend to configure them the same way though so...

[ajsutton]

It does work for me if I set the default for PLATFORMS to be the empty string.

variable "PLATFORMS" {
  // You can override this as "linux/amd64,linux/arm64".
  // Only a specify a single platform when `--load` ing into docker.
  // Multi-platform is supported when outputting to disk or pushing to a registry.
  // Multi-platform builds can be tested locally with:  --set="*.output=type=image,push=false"
  default = ""
}

That also seems to work in a linux VM for me but I don't have an intel linux machine to test with.

[ajsutton]

ok, confirmed it also works in an linux/amd64 VM and correctly generates amd images there. So I think no default value is the trick to make it work.