CI/CD Pipeline

How It Works

1. Push to GitHub — Developer pushes code to a branch (usually main or develop)

2. GitHub Actions triggers — Self-hosted runner on Contabo picks up the workflow

3. Build & Push — Docker image is built and pushed to Harbor at harbor.ayinza.dev

4. Deploy to Swarm — docker service update --image rolls out the new container

Self-Hosted Runners

Both runners run on Contabo (vmi2912133) as systemd services.

ayinza runner

• Service: actions.runner.ayinza.vmi2912133
• User: pk
• Org: github.com/ayinza

sseris runner

• Service: actions.runner.sseris.vmi2912133
• User: sharif
• Org: github.com/sseris

Managing Runners

# Check runner status
sudo systemctl status actions.runner.ayinza.vmi2912133
sudo systemctl status actions.runner.sseris.vmi2912133

# Restart a runner
sudo systemctl restart actions.runner.ayinza.vmi2912133

Artifact Repository

Property	Value
Tool	Sonatype Nexus 3
Address	84.247.134.135:8082
Purpose	Maven and npm dependency caching
Data	nexus-data volume (34 MB)

Note

The entire CI/CD pipeline runs on your own infrastructure — no external CI service, no cloud build minutes. GitHub Actions runners and the Docker registry are all self-hosted on Contabo.

Update Failure Protection

Docker Swarm won’t let a failed update take down a working service. If the new container fails to start or its health check fails, the old healthy container keeps running. The failed new task is rejected and the service continues serving traffic on the previous version.

This means a broken image push won’t break production — the existing service stays up. See Rollback Procedures for more details.