fix(docker): fall back to host arch for local builds

[elezar]

Summary

Fall back to the host architecture for local container builds when no explicit platform is configured. This was detected on a clean DGX Spark with Podman installed and Docker not runnable by the current user.

Related Issue

None.

Changes

• Added host architecture fallback in local container engine platform detection.
• Updated build documentation for local platform behavior.

Testing

• mise run pre-commit passes
• Unit tests added/updated (not applicable)
• E2E tests added/updated (not applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)

[ericcurtin]

This looks fine, but I feel like we could check arch in less places:

  case "$(uname -m)" in
    x86_64|amd64) echo "amd64" ;;
    aarch64|arm64) echo "arm64" ;;
    *) echo "$1" ;;
  esac

would cover almost everything except for Windows native. (ignoring emulation)

[elezar]

@ericcurtin what do you mean by:

we could check arch in less places:

We attempt to determine the architecture (for building th econtainers) from the container engine being used and only use the host architecture if these fail.

Note that this fixes the overly broad fallback from https://github.com/NVIDIA/OpenShell/pull/904/changes#diff-c175bbdd5dfb89f433966a57cb620726a4cd40dc35c58bfd2dd0b1ab0cc597d6R176-R182 which is only relevent on systems where neither docker nor podman works as expected and causes the mise build task to fail.

[ericcurtin]

Things like:

docker info --format '{{.Architecture}}'

and

uname -m

should always match (barring the aarch64/arm64 Linux/macOS thing). The only case where it doesn't is where the docker daemon is running in an environment that is of a different architecture (which may not be a corner case worth considering). Would be a mass simplification to just check "uname -m", but your choice

[elezar]

What about cases where the daemon is running remotely? The server architecture may be different from the client. With that said, we may want to check with @maxamillion on why the specific logic was chosen.

[maxamillion]

@elezar I honestly didn't go that far down the rabbit hole, I had not considered an use case where the container host could be remote

[maxamillion]

LGTM

[maxamillion]

@ericcurtin were there changes you wanted to see here or are we good to merge?

[ericcurtin]

@ericcurtin were there changes you wanted to see here or are we good to merge?

Oh sorry, this was always good :) I was just suggesting a simplification, not attempting to block