fix: use docker for arm builds

[aspectrr]

Description

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code style update (formatting, renaming)
• Code refactor (no functional changes)
• Configuration change
• Test update

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works

Release Notes

Labels

[claude]

Code Review: ARM Build Fix

Thank you for working on ARM build support! Here's my detailed review of the changes:

🟢 Positive Aspects

1. Correct approach: Using QEMU and cross-compilation toolchain for ARM64 builds is the right strategy
2. Complete toolchain setup: Installing both gcc/g++ cross-compilers and libvirt headers for both architectures
3. Proper CGO configuration: Setting CGO_LDFLAGS and PKG_CONFIG_PATH for ARM64 is essential for linking against the correct libraries

🔴 Critical Issues

1. Duplicate "Install Build Dependencies" step (.github/workflows/release.yaml:31-40 and 72-78)

The workflow now has TWO steps with the same name installing build dependencies. The second one (lines 72-78) will overwrite some of what the first one does and is missing multi-arch setup.

Impact: The sudo dpkg --add-architecture arm64 and libvirt-dev:arm64 installation from the first step may not be effective if packages are reinstalled.

Fix: Remove the duplicate step at lines 72-78 and keep only the comprehensive one at lines 31-40.

2. Missing qemu-user-static in the second install step

If you intended to have two separate steps, the second one is missing qemu-user-static which is required for cross-compilation.

⚠️ Potential Issues

3. Docker Buildx and QEMU setup unused

You're setting up Docker Buildx and QEMU (lines 25-29) but the actual build process uses native cross-compilation with aarch64-linux-gnu-gcc. These steps might be unnecessary unless you plan to use Docker-based builds.

Question: Are you planning to use Docker for builds in a future iteration, or can these steps be removed?

4. Redundant CGO_ENABLED=1 in .goreleaser.yaml

The .goreleaser.yaml changes add CGO_ENABLED=1 to both:

• Global env sections (lines 14, 49)
• Architecture-specific overrides (lines 35, 43, 70, 78)

Impact: Minor - the override values will take precedence, making the global setting redundant but harmless.

Suggestion: Remove CGO_ENABLED=1 from the global env sections since it's already set in overrides.

📋 Recommendations

Suggested .github/workflows/release.yaml fix:

- name: Install Build Dependencies
  run: |
    sudo dpkg --add-architecture arm64
    sudo apt-get update
    sudo apt-get install -y \
      gcc-aarch64-linux-gnu \
      g++-aarch64-linux-gnu \
      libvirt-dev:amd64 \
      libvirt-dev:arm64 \
      qemu-user-static

And remove the duplicate step at lines 72-78.

Optional .goreleaser.yaml cleanup:

Remove CGO_ENABLED=1 from the top-level env sections (lines 13-14 and 48-49) since you're explicitly setting it in all architecture overrides.

✅ Checklist Items

From the PR template, please confirm:

• Type of change marked (appears to be a bug fix)
• Self-review completed
• Tests added/updated (are there integration tests for ARM builds?)
• Release notes added (user-facing description of the fix)

🧪 Testing Suggestions

1. Verify ARM64 binaries are actually being cross-compiled (not just built)
2. Test that the ARM64 binaries work on actual ARM64 hardware/VMs
3. Confirm GPG signing works for both architectures
4. Check that both fluid and fluid-remote binaries are built successfully

Security Note

No security concerns identified - this is purely build infrastructure changes.

---

Severity Summary:

• 🔴 1 critical issue: Duplicate dependency installation step
• ⚠️ 2 minor issues: Unused Docker setup, redundant CGO settings
• Overall: Solid approach, needs minor cleanup

[Copilot]

Pull request overview

This PR updates the release pipeline and GoReleaser config to support Linux/arm64 builds that require CGO (libvirt), primarily by adding cross-compilation dependencies and arm64-specific linker/search paths.

Changes:

• Add arm64 CGO environment overrides in .goreleaser.yaml (including CGO_LDFLAGS and explicitly enabling CGO).
• Update the GitHub release workflow to install multi-arch build dependencies (arm64 + amd64 libvirt headers/libs and cross-compilers).
• Add QEMU/Buildx setup steps in the release workflow.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
.goreleaser.yaml	Adds/adjusts CGO-related env vars for linux/arm64 builds (libvirt tag builds).
.github/workflows/release.yaml	Installs arm64 toolchain + libvirt multiarch deps and adds Docker/QEMU setup steps to the release job.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The workflow sets up QEMU and Docker Buildx, but nothing later in this job uses Docker/Buildx (no docker buildx commands and no dockers: section in .goreleaser.yaml). This adds extra time/complexity without affecting the build. Either remove these steps, or update the release process/GoReleaser config to actually perform the ARM build inside Docker as intended by the PR title.

[Copilot]

qemu-user-static is installed via apt while the job also runs docker/setup-qemu-action. If the workflow isn't running target (arm64) binaries, neither is needed for cross-compiling with gcc-aarch64-linux-gnu; and if it is needed, having both is redundant. Consider dropping one (or both) to avoid longer installs and reduce maintenance surface.

Suggested change

	libvirt-dev:arm64 \
	qemu-user-static
	libvirt-dev:arm64

[Copilot]

CGO_ENABLED=1 is already set at the build level for fluid-remote, so repeating it in the per-arch override doesn’t change behavior and makes the config harder to scan. Consider keeping CGO_ENABLED only at the build level and leaving overrides for arch-specific settings (CC/CXX/PKG_CONFIG/CGO_LDFLAGS).

[Copilot]

Same redundancy here: CGO_ENABLED=1 is already set at the build level for fluid, so duplicating it in the linux/arm64 override adds noise without changing behavior. Consider removing it from the override and keeping only the arch-specific env vars.

Suggested change

- CGO_ENABLED=1