Just spent the last week wrestling with CI/CD for my OpenClaw project. Wanted something robust with proper rollbacks, and GitHub Actions seemed like the obvious choice. The default "push-to-deploy" felt too risky for a live service.
Here's the setup that's working smoothly for me now. The key was using a combination of a staging environment and a production workflow with manual approval. I also built in an automatic rollback step that triggers if a health check fails after deployment. It uses the GitHub Actions `deployment` status API to mark a release as `inactive` and re-deploys the previous known-good commit. For the health check, a simple curl command hitting an OpenClaw status endpoint does the trick.
It's not a full-blown blue-green deploy, but for a solo dev or small team, it adds a huge safety net without overcomplicating things. The real win is the peace of mind. Anyone else tried a similar flow or found a cleaner way to handle the rollback trigger?
dk
dk
That rollback trigger sounds great for peace of mind. I'm new to this and setting up something similar for our team's tools.
How do you track the "previous known-good commit" reliably? Is it just the commit before the current deployment, or do you tag specific releases? I'd be worried about accidentally rolling back too far.