Add @bartek as blocking since this is a build for the blob service. I love how clean this is!!

It seems like a really common issue that @jon's test plans don't reproduce in @atul's environment. I wonder how many of those issues happen because of macOS vs. NixOS, versus because of @atul having already ran through the whole mainline instructions

Can we update the Test Plan to include what operating systems and architectures the diff was tested on

Checked it out on aarch64-darwin

This works:

nix build .#comm-blob
./result/bin/blob

This does NOT:

nix build .#comm-blob.dockerImage
docker load -i ./result
docker run -i comm-blob

It fails with exec /bin/blob: exec format error

It looks like the image is built for a different architecture than mine. Am I missing something?

Yeah getting the following:

2022-11-29T20:34:15.301285632Z standard_init_linux.go:228: exec user process caused: exec format error

@jon it would save the whole team SO MUCH time if you started testing ALL OF your diffs on the same environment that literally everybody else uses: macOS

@jon it would save the whole team SO MUCH time if you started testing ALL OF your diffs on the same environment that literally everybody else uses: macOS

I'll be more clear about platform compatibility, never used the dockerImage with mac.

It looks like the image is built for a different architecture than mine. Am I missing something?

No, it's creating an oci container with the contents from the blob build, so if you're on an m1 mac, then you're creating container which has aarch64-darwin binary contents, but docker only understands linux.

Docker for mac creates a linux VM for you, and launches the containers inside of it.

Can you amend the Test Plan to include testing this on macOS, both Apple-based and Intel-based?

You should be able to build the binary on macos (e.g. `nix build .#comm-blob1), but the docker image will only be available on a linux host.

If you did want to do build the docker image on mac, then you would need to create a linux environment like starting a nix docker container, then attempting the build from within the docker image; this way nix will perceive the host as a linux machine. I'll add this to the test.

Ah dang, @bartek will that affect your work? I figure it's better for developer velocity to be able to build the Docker image without needing to manually stand up a VM for the build

It doesn't affect the blob service development as I'm doing it outside of Docker anyway.
It might affect other services development which depend on blob service. This is because our current yarn scripts (in services/ dir) build and run our services in docker. If running images wasn't possible anymore, they would need to be modified to run services directly/with Nix instead of Docker (this particular thing should be much easier when I'll get rid of last C++ service).

My opinion is that service Docker images should be only used to deploy services to staging/prod and they can be built on CI.

On the other hand, this particular diff doesn't conflict with any existing solution - it just adds another way to build the image so it doesn't break anything. So I'm totally OK with this one.

Do you foresee any need for developers to test building the Docker image locally? For keyserver development, I've found that if a diff causes a failure in the Docker keyserver CI job, it's easier for developers if they can locally test the Docker keyserver build, so they don't need to update the diff every time they want to test if a new approach works

Do you foresee any need for developers to test building the Docker image locally?

The integration tests currently run docker compose, which target the existing docker files.

For unit tests and writing code, this isn't necessary.

I'll scope this down to remove the docker image, it's a nice-to-have. It will be easy to add it back.

I don't think we should land this if we're not going to put it into CI, and I don't think we can land this with a CI job since people don't really have a way to iterate on it / test it.

Building the package can be done on any platform, I've reduced the scope to just include the binary package itself. Just building the package with nix has some advantages, as nix will cache all successful builds, and cargo support in nixpkgs right now allows for all the dependencies to be cached in the nix store as well, so iterating "clean" builds, is very quick. cargo fetch is skipped if the lock file hasn't changed, and the entire build will be skipped if the proto and blob directories are the same.

My instinct is that we should stick with Dockerfile builds in the short-term, until we're in a position to prioritize the aforementioned "Nix Docker build on macOS" stuff. Open to being convinced

Seems fine with me.