spikerj/spikersoft-issues
1
0
Fork 0
Code Issues 196 Pull Requests Actions Packages Projects Releases Wiki Activity

ci(artpipe): image push only redeploys the modeling stack — five resident model stacks go stale; PR builds overwrite prod :latest #471

New Issue
Closed
opened 2026-07-11 04:35:51 +00:00 by spikerj · 1 comment
spikerj commented 2026-07-11 04:35:51 +00:00
Owner
Copy Link
Copy Source

Summary

All six artpipe Swarm stacks run the same image git.spikersoft.com/spikerj/spikersoft-artpipe-processor:latest:

  • spikersoft-artpipe-modeling (per-stage fallback lane)
  • spikersoft-artpipe-model-sdxl, -triposr, -safety, -hunyuan (GPU residents, docker-stack-gpu.yml)
  • spikersoft-artpipe-model-blender (CPU resident, docker-stack.yml)

But the CI workflow spikersoft-backend/.gitea/workflows/spikersoft-artpipe-processor.yml only redeploys spikersoft-artpipe-modeling after building and pushing a new image. The five resident model stacks keep running whatever container they had at their last manual deploy, so every CI image push drifts the residents (which serve the production stages) away from the fallback lane.

The cutover runbook (spikersoft-infrastructure/docs/artpipe-server-cutover-runbook.md §3) already documents the intended behavior — “After this, the ArtPipeProcessor CI workflow redeploys all six on every image push” — the workflow just doesn't do it.

Secondary problem

The workflow's pull_request trigger runs the same build_and_publish job, which pushes the prod :latest tag (and the downstream deploy job then redeploys prod) from unmerged PR code.

Proposed fix

In spikersoft-artpipe-processor.yml:

  1. Extend the deploy job's SSH script to redeploy all six stacks, mirroring runbook §3 (five with docker-stack-gpu.yml, blender with docker-stack.yml, each docker stack deploy --with-registry-auth from /mnt/infrastructure/<stack>).
  2. Gate the registry push, deploy, and notify steps/jobs so they only run on master pushes / workflow_dispatch — PR builds keep the Docker build as a check but never touch the registry or prod.

spikersoft-artstudio-metrics is unaffected (has its own workflow).

Repo: spikersoft-backend

## Summary All six artpipe Swarm stacks run the same image `git.spikersoft.com/spikerj/spikersoft-artpipe-processor:latest`: - `spikersoft-artpipe-modeling` (per-stage fallback lane) - `spikersoft-artpipe-model-sdxl`, `-triposr`, `-safety`, `-hunyuan` (GPU residents, `docker-stack-gpu.yml`) - `spikersoft-artpipe-model-blender` (CPU resident, `docker-stack.yml`) But the CI workflow `spikersoft-backend/.gitea/workflows/spikersoft-artpipe-processor.yml` only redeploys **`spikersoft-artpipe-modeling`** after building and pushing a new image. The five resident model stacks keep running whatever container they had at their last manual deploy, so every CI image push drifts the residents (which serve the production stages) away from the fallback lane. The cutover runbook (`spikersoft-infrastructure/docs/artpipe-server-cutover-runbook.md` §3) already documents the intended behavior — “After this, the ArtPipeProcessor CI workflow redeploys all six on every image push” — the workflow just doesn't do it. ## Secondary problem The workflow's `pull_request` trigger runs the same `build_and_publish` job, which **pushes the prod `:latest` tag** (and the downstream `deploy` job then redeploys prod) from unmerged PR code. ## Proposed fix In `spikersoft-artpipe-processor.yml`: 1. Extend the deploy job's SSH script to redeploy all six stacks, mirroring runbook §3 (five with `docker-stack-gpu.yml`, blender with `docker-stack.yml`, each `docker stack deploy --with-registry-auth` from `/mnt/infrastructure/<stack>`). 2. Gate the registry push, deploy, and notify steps/jobs so they only run on master pushes / `workflow_dispatch` — PR builds keep the Docker build as a check but never touch the registry or prod. `spikersoft-artstudio-metrics` is unaffected (has its own workflow). Repo: `spikersoft-backend`
spikerj commented 2026-07-11 23:26:27 +00:00
Author
Owner
Copy Link
Copy Source

Resolved in spikersoft-backend PR #200 (merged): image push now redeploys all six artpipe stacks, and PR builds stay off the registry/prod :latest. Closing.

Resolved in spikersoft-backend PR #200 (merged): image push now redeploys all six artpipe stacks, and PR builds stay off the registry/prod :latest. Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agentic
Actionable surfaced by the agentic architecture & security review
 bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 sonarqube
Code quality issue surfaced by SonarQube (bug / code smell)
 wontfix
This won't be fixed
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
spikerj (Joseph Spiker)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#471