Claude/update prod runner script lq2g s

[gamblecodezcom]

User description

Summary by CodeRabbit

• New Features

  • Enhanced deployment notifications for admins (richer status, source labeling, and alerting via configured bot).
  • Deploy command now triggers a background deployment process and returns promptly.

• Chores

  • Centralized VPS deployment into a single scripted flow.
  • CI/CD updated to run deployments only for merged PRs to main or manual triggers and to enforce quality gates before deploy.

---

CodeAnt-AI Description

Post rotating silent tips to the prize group and enforce VPS-only runtime; use safe fetch+reset deploys

What Changed

• Bot now posts a random, silent "tip" to the configured prize group every configurable interval; tips persist across restarts and scheduler starts on bot launch
• Admins can manage tips via new commands and dashboard: view, add, edit, remove, enable/disable, test, and change the posting interval
• Runtime now exits unless running on a VPS (DEVICE=vps) or explicitly in CI/disabled-runtime mode, preventing accidental local or CI bot startups
• Deploy flow switched to fetch + hard reset (avoids hangs on dirty trees); deploy command and prod scripts skip work if the server already matches origin/main
• Added a VPS deploy script (deploy.sh) and updated GitHub Actions to stop performing live deploys; CI only runs quality gates on merged PRs or manual runs

Impact

✅ Regular silent tips posted to prize group
✅ Fewer accidental production restarts from GitHub Actions
✅ Safer deployments that skip if VPS is already up-to-date

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[codeant-ai]

CodeAnt AI is reviewing your PR.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[coderabbitai]

Warning

Rate limit exceeded

@gamblecodezcom has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 6 minutes and 19 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📝 Walkthrough

Walkthrough

Replaces push-to-main CI trigger with PR-closed (merge) gating, centralizes VPS deployment into a single deploy.sh invoked over SSH with key+password fallback and admin notifications, and updates the bot to launch deployments by spawning the deploy.sh script rather than performing in-process git/npm/service steps.

Changes

Cohort / File(s)	Summary
CI/CD Workflow .github/workflows/deploy.yml	Trigger changed from push-to-main to pull_request closed/merge and workflow_dispatch; quality-gates conditionally run only for PR merges or manual runs; Deploy job renamed/enabled and gated on quality-gates.
VPS Deploy Script deploy.sh	Consolidated VPS deploy logic into deploy.sh: pre-checks to skip unchanged deploys, key + password SSH attempts, sshpass install, robust git fetch/reset with failure guards, npm ci/install logic, systemd start/restart adjustments, trap-based error reporting, and Telegram admin notifications via BOT_TOKEN/ADMIN_IDS.
Bot Entrypoint index.js	/deploy command no longer runs git/npm/service operations inline; spawns a detached deploy.sh on the VPS and returns quickly after persisting state and sending initial reply; removes in-process multi-step progress updates and restart orchestration.

Sequence Diagrams

sequenceDiagram
    actor GH as GitHub Actions
    participant QG as Quality Gates
    participant Deploy as Deploy Job (GH)
    participant SSH as SSH Client (Actions -> VPS)
    participant VPS as VPS Server (runs deploy.sh)
    participant Service as systemd Service
    participant Bot as Telegram Bot (Admin notifications)

    GH->>GH: PR closed/merged to main
    GH->>QG: run quality gates (conditional)
    alt Quality gates pass
        QG-->>Deploy: success
        Deploy->>SSH: SSH -> run `deploy.sh` (key first, password fallback)
        SSH->>VPS: invoke `deploy.sh`
        VPS->>VPS: verify main hash vs remote (skip if identical)
        alt Update needed
            VPS->>Service: systemctl stop/start/restart as needed
            VPS->>VPS: git fetch & hard reset origin/main
            VPS->>VPS: npm ci / npm install (production deps)
            VPS->>Service: systemctl start/restart service
            VPS->>VPS: health checks & status reporting
        else Up-to-date
            VPS->>VPS: skip deploy, log
        end
        VPS->>Bot: send admin notifications (start, progress, success/failure)
        VPS-->>Deploy: exit status/report
    else Quality gates fail
        QG-->>Deploy: skip deployment
    end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 I hopped from branch to branch with glee,
Deploy.sh carried the load for me,
Keys first, then passwords if need be,
Telegram bells chimed success to see,
A tidy deploy, snug as a pea. 🥕

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codeant-ai]

Nitpicks 🔍

🔒 No security issues identified

⚡ Recommended areas for review Remote hash check race/fallback The preliminary skip-deploy check compares git ls-remote to local HEAD and exits early if equal. If the remote is temporarily unreachable or git ls-remote returns nothing, it falls back to proceeding. Conversely, there's a small race between ls-remote and the later fetch/reset steps. Consider fetching first and comparing origin/main directly (or handle unreachable remotes explicitly). Git fetch/reset robustness The new combined conditional uses git -C ... fetch --all && git -C ... reset --hard origin/main. If origin/main is missing, unreachable, or reset fails for any reason, the script will silently continue with the local copy. This can hide why deployments didn't pull updates and may leave the instance running old code. Consider separating fetch and reset, verify that origin/main exists, and preserve/log git output on failure. PID detection fragility get_bot_pid() uses a pgrep -f regex based on the literal PROJECT_DIR path. If the path contains spaces, special chars, or the process command-line differs (e.g., launched via a wrapper), detection may fail or match unrelated processes. Consider escaping/sanitizing the pattern or using an explicit PID file for the service. Debug info on Git failures The failure branch only warns ("Git fetch/reset failed — continuing with local copy") without any diagnostic output. This makes post-mortems hard. Capture and include git stderr/stdout in warnings so an operator can know whether the network, remote, auth, or ref-not-found caused the failure.

[codeant-ai]

Suggestion: The deployment script stops the systemd service before running git fetch/reset, but because set -e is enabled and those git commands are not guarded, any git failure (e.g., network/remote issues or a non-git directory) will abort the script after the service has been stopped, leaving the application permanently down even though no new code was deployed; wrapping the git operations in a conditional and explicitly restarting the existing service on failure prevents this unintended downtime. [logic error]

Severity Level: Critical 🚨

- ❌ Failed deploy leaves runewager.service stopped indefinitely.
- ❌ All Runewager bot functionality unavailable after git failure.
- ⚠️ Manual intervention required to restart production service.

Suggested change

	git fetch --all
	git reset --hard origin/main
	git clean -fd
	say "Now at: $(git rev-parse --short HEAD)"
	if git fetch --all && git reset --hard origin/main; then
	git clean -fd
	say "Now at: $(git rev-parse --short HEAD)"
	else
	warn "Git fetch/reset failed — restarting existing service without deploying new code"
	if command -v systemctl >/dev/null 2>&1; then
	systemctl start "${APP_NAME}.service" || true
	fi
	exit 1
	fi

Steps of Reproduction ✅

1. On the VPS where Runewager runs, ensure `runewager.service` is active by running
`systemctl status runewager.service` (this is the service the script manages at
`deploy.sh:46-48,75-77`).

2. Create a realistic git failure condition for the deployment repo at
`/var/www/html/Runewager` (the script's `PROJECT_DIR` at `deploy.sh:19,29`) by, for
example, temporarily misconfiguring `origin` or blocking outbound network so that `git
fetch --all` will fail with a non‑zero exit status.

3. From the VPS, run the deployment script exactly as documented in the header comment at
`deploy.sh:8-9`: `bash /var/www/html/Runewager/deploy.sh`; the script will pass the
"already up to date" check at `deploy.sh:31-41`, then stop the service via `systemctl stop
"runewager.service"` at `deploy.sh:43-49`.

4. When the script reaches the unguarded `git fetch --all` / `git reset --hard
origin/main` commands at `deploy.sh:54-56` under `set -euo pipefail` at `deploy.sh:17`,
the failing git command exits non‑zero, causing the whole script to abort before the
restart block at `deploy.sh:71-77`; re‑run `systemctl status runewager.service` and
observe that the service is left in a stopped state with no new code deployed.

Prompt for AI Agent 🤖

This is a comment left during a code review.

**Path:** deploy.sh
**Line:** 55:58
**Comment:**
	*Logic Error: The deployment script stops the systemd service before running `git fetch/reset`, but because `set -e` is enabled and those git commands are not guarded, any git failure (e.g., network/remote issues or a non-git directory) will abort the script after the service has been stopped, leaving the application permanently down even though no new code was deployed; wrapping the git operations in a conditional and explicitly restarting the existing service on failure prevents this unintended downtime.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.

👍 | 👎

[codeant-ai]

CodeAnt AI finished reviewing your PR.