This document explains how to manually trigger the build processes for Stigix using the GitHub CLI (gh).
Builds and pushes the 5 separate images (stigix, sdwan-traffic-gen, sdwan-voice-gen, sdwan-voice-echo, sdwan-mcp-server).
Triggers a build for the current branch (usually main).
gh workflow run docker-build.ymlBuilds for both AMD64 and ARM64 and tags them as stable.
gh workflow run docker-build.yml -f version_to_stable=1.2.3 -f build_full=trueBuilds and pushes the single combined image jsuzanne/stigix.
Triggers a build of the all-in-one image for the current branch.
gh workflow run build-stigix-allinone.ymlBuilds the all-in-one image for both platforms and tags it as stable.
gh workflow run build-stigix-allinone.yml -f version_to_stable=1.2.3 -f build_full=trueIf you want to produce both individual containers and the all-in-one container for a specific version (e.g., 1.2.1-patch.152), simply push a Git tag:
git tag v1.2.1-patch.152
git push origin v1.2.1-patch.152What happens next:
- Workflow A triggers: produces 5 images tagged
1.2.1-patch.152 - Workflow B triggers: produces 1 image
jsuzanne/stigix:1.2.1-patch.152
It makes perfect sense to build them independently if you only changed one component.
Use this if you fixed something in web-dashboard and only want to update those specific images.
gh workflow run docker-build.yml -f version_to_stable=1.2.1-patch.153Use this if you fixed a packaging issue in the supervisor config or the all-in-one Dockerfile.
gh workflow run build-stigix-allinone.yml -f version_to_stable=1.2.1-patch.153| Method | Result | Best for... |
|---|---|---|
Git Tag (v*) |
Builds Both A + B | Formal releases, matching source to images. |
| Push to main | Builds Both A + B (:latest) |
Continuous integration / Dev updates. |
| GH CLI (Manual) | Builds Only requested file | Targeted fixes, testing build logic, or partial updates. |