release: ship the daemon only, drop the controller artifacts

The controller stopped being a deployed artifact when Nebula started
linking it into its own manager process through the C ABI
(server/src/ffi.rs). A daemon's connection is a live socket owned by
whichever process accepted it, so reaching a workload from a separate
controller process would mean relaying.

That left the release publishing two things nothing consumes: the
sandd-controller binaries and the inftyai/sandd-controller image.
Publishing them implies a supported deployment shape that has no users,
so drop both matrix legs and the controller-image job. The daemon
assets are untouched.

`cargo build --bin sandd-controller` and `make docker-build-controller`
still work for running it standalone.

Also fix a Makefile comment that pointed at
internal/controller/pod_placement_controller.go, a path whose SandD code
was deleted.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: kerthcet <kerthcet@gmail.com>

Author: kerthcet

.github/workflows/release.yaml

@@ -40,23 +40,17 @@ jobs:
             asset: sandd-darwin-arm64
             package: sandd
             bin: sandd
-          # The CONTROLLER. Linux-only, unlike the daemon: the daemon runs on
-          # whatever a provider's instance is (including a dev Mac), while the
-          # controller only ever runs as a container in a cluster. A darwin leg
-          # would be an asset nothing consumes.
+          # THE DAEMON ONLY. There is deliberately no sandd-controller asset and no
+          # controller image: the controller is not a deployed artifact any more. Its
+          # only consumer, Nebula, compiles it INTO its manager process through the C
+          # ABI (server/src/ffi.rs), because a daemon's connection is a live socket
+          # owned by whichever process accepted it — so reaching back into a workload
+          # from a separate controller process would mean relaying.
           #
-          # No --features python — the pyo3 layer is optional and must stay out or
-          # the bin cannot link at all (see server/Cargo.toml).
-          - runner: ubuntu-22.04
-            target: x86_64-unknown-linux-musl
-            asset: sandd-controller-linux-amd64
-            package: sandbox-server
-            bin: sandd-controller
-          - runner: ubuntu-22.04-arm
-            target: aarch64-unknown-linux-musl
-            asset: sandd-controller-linux-arm64
-            package: sandbox-server
-            bin: sandd-controller
+          # `cargo build --bin sandd-controller` and `make docker-build-controller`
+          # still work for anyone who wants to run it standalone. They are just not
+          # release artifacts, and publishing them would imply a supported deployment
+          # shape that nothing uses.
     steps:
       - uses: actions/checkout@v4
 
@@ -113,9 +107,8 @@ jobs:
       - name: Generate checksums
         run: |
           cd artifacts
-          # `sandd-*` covers the controller assets too (sandd-controller-linux-*),
-          # so both binaries are checksummed by the one file consumers already read.
-          # Excluded explicitly so a re-run cannot hash a previous checksums file.
+          # The checksums file is excluded from its own input, so a re-run of this
+          # workflow cannot hash the file it is about to overwrite.
           sha256sum $(ls sandd-* | grep -v '^sandd-checksums.txt$') > sandd-checksums.txt
           cat sandd-checksums.txt
 
@@ -139,70 +132,3 @@ jobs:
               --generate-notes \
               artifacts/*
           fi
-
-  # The controller IMAGE — what Nebula actually pulls
-  # (DefaultSandDControllerImage = inftyai/sandd-controller:latest).
-  #
-  # A separate job, NOT `needs: build`: buildx compiles the binary itself inside the
-  # Dockerfile, so gating on the binary legs would serialize two independent builds
-  # and let a darwin-runner hiccup block the image. It also means a failed push does
-  # not hold back the GitHub release.
-  #
-  # REQUIRES SECRETS: DOCKERHUB_USERNAME and DOCKERHUB_TOKEN (a Docker Hub access
-  # token with write access to inftyai/sandd-controller). Until they exist this job
-  # fails at the login step — deliberately loud rather than silently skipped, since a
-  # tagged release with no matching image is exactly the state that is confusing to
-  # debug later.
-  controller-image:
-    name: Publish controller image
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      # QEMU so the arm64 leg can be built on an amd64 runner. Slower than a native
-      # arm runner, but it keeps this a single job producing ONE manifest — a
-      # per-arch matrix would need a separate merge step to assemble it.
-      - name: Set up QEMU
-        uses: docker/setup-qemu-action@v3
-
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
-
-      - name: Log in to Docker Hub
-        uses: docker/login-action@v3
-        with:
-          username: ${{ secrets.DOCKERHUB_USERNAME }}
-          password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-      # Both arches as ONE manifest, so a node pulling the tag gets its own
-      # architecture. Same platforms the Makefile's docker-push-controller uses.
-      #
-      # `latest` moves with every tag because that is what
-      # DefaultSandDControllerImage points at; the version tag is the immutable one to
-      # pin in production.
-      - name: Build and push
-        uses: docker/build-push-action@v6
-        with:
-          context: .
-          file: hack/docker/Dockerfile.controller
-          platforms: linux/amd64,linux/arm64
-          push: true
-          tags: |
-            inftyai/sandd-controller:${{ github.ref_name }}
-            inftyai/sandd-controller:latest
-          # Cache through the registry: each release starts from a cold runner, and a
-          # from-scratch dependency compile is the bulk of this job.
-          cache-from: type=registry,ref=inftyai/sandd-controller:buildcache
-          cache-to: type=registry,ref=inftyai/sandd-controller:buildcache,mode=max
-
-      # Proves the pushed manifest is actually multi-arch and that the binary in it
-      # runs. A single-arch push dies on the node with "exec format error", which is
-      # a far worse place to discover it.
-      - name: Verify the pushed manifest
-        run: |
-          docker buildx imagetools inspect inftyai/sandd-controller:${{ github.ref_name }}
-          for arch in amd64 arm64; do
-            echo "--- linux/$arch ---"
-            docker run --rm --platform "linux/$arch" \
-              inftyai/sandd-controller:${{ github.ref_name }} --version
-          done

Makefile

@@ -116,8 +116,11 @@ docker-down:
 
 # --- Controller image (native Rust binary) -------------------------------------
 #
-# This is the image Nebula pulls: DefaultSandDControllerImage in Nebula's
-# internal/controller/pod_placement_controller.go is inftyai/sandd-controller:latest.
+# For running the controller STANDALONE. Nebula does not pull this: it links the
+# controller into its own manager through the C ABI (server/src/ffi.rs), so there is
+# no controller Deployment and no image to pin. Nothing publishes this image either
+# — the release workflow ships the daemon binaries only.
+#
 # Distroless + one static-ish binary, ~50MB against the ~4GB server-tunnel image
 # below, because it carries no interpreter, no rustup and no Tailscale client.
 #