git-workflow-restart

Restarts production containers manually with sha-pinned Docker images and log-based verification.

1|Updated Jan 14, 2024
One-click install
npx skills add https://github.com/Eyhenij/rt-tools --skill git-workflow-restart-eyhenij
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-workflow-restart
Source: https://github.com/Eyhenij/rt-tools/tree/main/.claude/skills/git-workflow-restart
Command: npx skills add https://github.com/Eyhenij/rt-tools --skill git-workflow-restart-eyhenij

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Manual production restarts often silently roll back to stale images because docker compose defaults to the latest tag, which lags behind the main branch. This Skill provides the exact commands and verification steps to restart containers with the correct commit-sha image tag and confirm the rollout actually happened. ## Core Features & Use Cases - Sha-pinned restart commands: Ready-made docker compose commands that set IMAGE_TAG to the commit sha so production never falls back to a stale latest image. - Log-based verification: Explains why HTTP response codes cannot confirm a rollout and shows which log lines (e.g., the startup digest with integrations) prove the new image is running. - Rollback procedure: Describes rollback as the same sha-pinned startup using a previous tag, including how to list the last three retained image tags in the registry. - Use Case: After editing .env.prod, you need to bring the container up again on the server. Use this Skill to pull and start the exact image by sha, then verify the expected log lines appear. ## Quick Start Ask the assistant to restart production manually with the correct image sha and verify the rollout from the container logs.

Frequently Asked Questions about git-workflow-restart

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I restart a production Docker container with a specific image tag?

Set the IMAGE_TAG variable to the commit sha before running docker compose pull and up with the production compose file and env file. Without the variable, compose substitutes the default latest tag, which may lag behind the main branch.

Why does production roll back to an old image after a manual restart?

Docker compose defaults to the latest tag when IMAGE_TAG is unset, and latest in the registry often lags behind main. The container keeps responding, so the rollback is silent unless you check the image sha and logs.

How do I verify a deployment actually rolled out?

Check the container logs for expected startup lines, such as the startup digest with integrations, rather than relying on HTTP response codes. A substituted image keeps answering requests while missing the new code's log lines.

How do I roll back a Docker deployment to a previous image?

Run the same sha-pinned startup command with the previous commit sha. List the last three retained tags from the registry with docker image ls, since cleanup keeps only three and deeper rollback is impossible.

Does rolling back the image also roll back database migrations?

No. A rollback returns the previous image but not the previous storage schema; applied migrations stay in place. That is why schema changes are split into compatible and incompatible migrations handled by a separate migration pattern.