Add macOS ARM64 smoke test for container validation

[Mossaka]

Summary

• Adds a new smoke-macos-arm64 agentic workflow that runs on macos-latest (Apple Silicon ARM64 runner)
• Validates that ARM64 container images work correctly: firewall agent, squid, api-proxy, and MCP gateway (ghcr.io/github/gh-aw-firewall/*:v0.20.0, ghcr.io/github/gh-aw-mcpg:v0.1.4)
• Agent instructions match smoke-copilot with additional ARM64-specific tests: architecture verification, Docker availability, ARM64 image pull/inspect, and container startup validation

Test plan

• Compile succeeds (gh aw compile .github/workflows/smoke-macos-arm64.md)
• Lock file has runs-on: macos-latest on the agent job
• Trigger with smoke label to validate end-to-end on a macOS ARM64 runner
• Verify container images pull and start as ARM64 on Apple Silicon

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR adds a new smoke test workflow for validating ARM64 container images on macOS Apple Silicon (ARM64) runners. The workflow tests that firewall agent, squid, api-proxy, and MCP gateway containers work correctly on the ARM64 architecture.

Changes:

• New smoke-macos-arm64.md workflow that runs on macos-latest runners
• Tests ARM64 container image functionality with architecture verification, Docker availability checks, container pull/inspect tests, and startup validation
• Includes comprehensive testing of MCP servers (GitHub, Serena, Playwright), safe inputs/outputs, and workflow dispatch capabilities

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.

File	Description
.github/workflows/smoke-macos-arm64.md	New workflow definition for macOS ARM64 smoke tests with container validation instructions
.github/workflows/smoke-macos-arm64.lock.yml	Generated lock file with compiled workflow YAML configuration

---

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

[Copilot]

There is an inconsistency in how firewall container image versions are specified. In the test instructions (lines 125-128), the images are referenced with the "v" prefix:

• ghcr.io/github/gh-aw-firewall/agent:v0.20.0
• ghcr.io/github/gh-aw-firewall/squid:v0.20.0
• ghcr.io/github/gh-aw-firewall/api-proxy:v0.20.0

However, in the generated lock file (line 477), these same images are downloaded without the "v" prefix:

• ghcr.io/github/gh-aw-firewall/agent:0.20.0
• ghcr.io/github/gh-aw-firewall/api-proxy:0.20.0
• ghcr.io/github/gh-aw-firewall/squid:0.20.0

While in line 1644 of the lock file, the --image-tag flag correctly uses 0.20.0 without the "v" prefix.

The agent will attempt to pull images with the "v" prefix (as instructed in lines 125-128, 131-134) but those images may not exist if only the non-prefixed versions are available in the registry. Please ensure consistency: either add the "v" prefix to all references or remove it from the test instructions.

Suggested change

	- `ghcr.io/github/gh-aw-firewall/agent:v0.20.0`
	- `ghcr.io/github/gh-aw-firewall/squid:v0.20.0`
	- `ghcr.io/github/gh-aw-firewall/api-proxy:v0.20.0`
	- `ghcr.io/github/gh-aw-mcpg:v0.1.4`
	For each image, run `docker inspect --format '{{.Architecture}}' <image>` and verify it reports `arm64`.
	4. **Container Startup Test**: For each pulled image, attempt to start a container and verify it runs without crash:
	- For `agent`: `docker run --rm ghcr.io/github/gh-aw-firewall/agent:v0.20.0 echo "agent OK"`
	- For `squid`: `docker run --rm -d --name smoke-squid ghcr.io/github/gh-aw-firewall/squid:v0.20.0` then check it's running with `docker ps`, then `docker stop smoke-squid`
	- For `api-proxy`: `docker run --rm ghcr.io/github/gh-aw-firewall/api-proxy:v0.20.0 --help` (or similar basic invocation)
	- For `mcpg`: `docker run --rm ghcr.io/github/gh-aw-mcpg:v0.1.4 --help` (or similar basic invocation)
	- `ghcr.io/github/gh-aw-firewall/agent:0.20.0`
	- `ghcr.io/github/gh-aw-firewall/squid:0.20.0`
	- `ghcr.io/github/gh-aw-firewall/api-proxy:0.20.0`
	- `ghcr.io/github/gh-aw-mcpg:0.1.4`
	For each image, run `docker inspect --format '{{.Architecture}}' <image>` and verify it reports `arm64`.
	4. **Container Startup Test**: For each pulled image, attempt to start a container and verify it runs without crash:
	- For `agent`: `docker run --rm ghcr.io/github/gh-aw-firewall/agent:0.20.0 echo "agent OK"`
	- For `squid`: `docker run --rm -d --name smoke-squid ghcr.io/github/gh-aw-firewall/squid:0.20.0` then check it's running with `docker ps`, then `docker stop smoke-squid`
	- For `api-proxy`: `docker run --rm ghcr.io/github/gh-aw-firewall/api-proxy:0.20.0 --help` (or similar basic invocation)
	- For `mcpg`: `docker run --rm ghcr.io/github/gh-aw-mcpg:0.1.4 --help` (or similar basic invocation)

[pelikhan]

Gh-aw is probably not working. It gets enabled with tools.agentic-workflows

[github-actions]

Hey @Mossaka 👋 — thanks for adding macOS ARM64 smoke test coverage! This is exactly the kind of infrastructure work that helps ensure multi-architecture support. The technical implementation looks solid: comprehensive test coverage, proper workflow configuration, and good test plan.

However, there's a process concern to address:

• Missing agentic plan — Per CONTRIBUTING.md, contributions should start with an issue containing a detailed agentic plan, which GitHub Copilot Agent then implements in a PR. This PR was created directly without an associated issue/plan.
• Traditional PRs are not enabled — The contribution guidelines explicitly state: "Traditional pull requests are not enabled. Instead, you craft a complete agentic plan that GitHub Copilot Agent will execute."

While you're a collaborator and this is infrastructure work (which may have different internal processes), the documented workflow expects all changes to flow through the issue → agent → PR pipeline.

Suggested Path Forward

If you'd like to align with the documented process:

1. Create an issue with an agentic plan describing this work
2. Reference this PR in the issue as a proof-of-concept
3. Assign the issue to GitHub Copilot Agent
4. Let the agent create a new PR following the plan

Alternatively, if internal contributors have different guidelines for infrastructure work, consider documenting that exception in CONTRIBUTING.md to avoid confusion.

Generated by Contribution Check