Add stub implementations to make buildkitd buildable for Darwin

[slonopotamus]

These changes are extracted from #4059. Other half was already merged in #5271.

localmounter_darwin.go is fully identical to localmounter_freebsd.go except that it uses bind mount type instead of FreeBSD-specific nullfs.

Not sure whether you want to enable CI job for Darwin buildkitd, I'm absolutely OK if that will be omitted from current PR.

[tonistiigi]

We do not want to ship stub buildkitd binary for macos users.

[slonopotamus]

Okay, will remove from here. Do you want me to add another job that would check that it compiles?

[crazy-max]

You can add it to this matrix:

buildkit/.github/workflows/test-os.yml

Lines 33 to 35 in ea6f91e

	platform:
	- windows/amd64
	- freebsd/amd64

      matrix:
        platform:
          - windows/amd64
          - freebsd/amd64
          - darwin/amd64

[slonopotamus]

If I read things properly, that job goes through the same Dockerfile target (binaries-darwin), so it won't build buildkitd.

[crazy-max]

Hum right it will build binaries-for-test target:

buildkit/.github/workflows/test-os.yml

Line 57 in ea6f91e

targets: binaries-for-test

buildkit/docker-bake.hcl

Lines 102 to 106 in ea6f91e

	target "binaries-for-test" {
	inherits = ["_common"]
	target = "binaries-for-test"
	output = [bindir("build")]
	}

buildkit/Dockerfile

Lines 367 to 371 in ea6f91e

	FROM scratch AS binaries-for-test
	COPY --link --from=gotestsum /out /
	COPY --link --from=registry /out /
	COPY --link --from=containerd /out /
	COPY --link --from=binaries / /

We would just want buildctl and buildkitd

[slonopotamus]

Soo... Do you want me to add COPY --link --from=buildkitd /usr/bin/buildkitd / to binaries-for-test? It will do redundant work for other platforms, but I don't see any other good way.

[crazy-max]

I guess we can create a dedicated job in test-os workflow to build buildkitd target for darwin/amd64 platform. I can push these changes to your branch if you want.

[slonopotamus]

I can push these changes to your branch if you want.

That would be cool!

[slonopotamus]

@crazy-max It looks like you stopped building buildctl this way. I have no experience with docker/bake-action, is it possible to ask it to build multiple targets?

[crazy-max]

I changed the workflow to create a dedicated job instead to just build buildkitd. buildctl is already built here:

buildkit/.github/workflows/buildkit.yml

Line 69 in b60d621

binaries:

e.g., https://github.com/moby/buildkit/actions/runs/10665890596/job/29560219583

[slonopotamus]

Looks good, thanks for help

[tonistiigi]

So what's the benefit of this? I would get if some packages are useful for darwin and we want to make sure that they are buildable. But why build a broken buildkitd. Why make executor "buildable" when there really is no implementation. Why make source/git "buildable" while with this PR it would just fail on runtime as soon as it would get called?

We have no intention of actually supporting macos as target via some non-container execution mechanism https://github.com/moby/buildkit/blob/master/PROJECT.md#project-scope .

[slonopotamus]

WRT source/git: I believe it is a very marginal functionality that can be added at a later point when anyone actually needs it.

WRT executor: I do not agree that there is no implementation. Everything that buildkit needs is to call containerd (and current PR enables containerd worker). There are multiple containerd runtimes that work on Darwin, for example https://github.com/ukontainer/runu/

I do not expect any significant Darwin-specific changes to buildkit besides current PR.

[slonopotamus]

Looks like CI failed on master branch after this PR was merged. I believe it is not related to my changes, and is caused by hashicorp/vagrant#13501 and the fact that FreeBSD job doesn't lock specific versions of tools (vargant+virtualbox).