Skip to content

add script to reset demo systems via cron or manually - #522

Open
rolandpickl wants to merge 2 commits into
mainfrom
feature/delete-demo-instance-content-script
Open

add script to reset demo systems via cron or manually#522
rolandpickl wants to merge 2 commits into
mainfrom
feature/delete-demo-instance-content-script

Conversation

@rolandpickl

@rolandpickl rolandpickl commented Jun 8, 2026

Copy link
Copy Markdown
Collaborator

Summary

add a script to reset the contents of the demo system in order to be able to make the demo system public available.

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • 📝 Documentation update
  • ♻️ Refactoring (no functional changes)
  • 🔧 Chore (dependency updates, CI changes, etc.)

Related Issue

Closes #

Changes Made

  • added a new script

How to Test

  1. check if the eddi demo system is deleted every 48 hours.

Checklist

  • My code follows the project's code style
  • I have added tests that prove my fix/feature works
  • Existing tests pass locally (./mvnw clean verify -DskipITs)
  • I have updated documentation if needed
  • My commit messages follow conventional commits
  • I have not committed any secrets, API keys, or tokens
  • This PR has a clear, focused scope (one concern per PR)

Summary by CodeRabbit

  • New Features
    • Automated periodic demo reset: clears session/runtime data, restarts the service, waits for readiness, and reimports initial agents to restore demo state.
    • VM install command: adds an install-and-schedule option to deploy the reset mechanism on a VM with a systemd timer (runs every 48h) and guidance for manual triggering and logs.

@rolandpickl
rolandpickl requested a review from ginccc as a code owner June 8, 2026 08:36
@coderabbitai

coderabbitai Bot commented Jun 8, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

Adds a new gcp/eddi-demo-reset.sh that clears selected MongoDB runtime collections, restarts EDDI, waits for readiness, and re-imports initial agents. Extends gcp/provision-vm.sh with an install-reset command that uploads the script to a VM and schedules it using a systemd service + timer (every 48h, runs after boot).

Changes

Demo Reset Automation

Layer / File(s) Summary
Reset script initialization and configuration
gcp/eddi-demo-reset.sh
Script header and strict shell semantics (set -euo pipefail); defines EDDI_DIR, EDDI_PORT, logfile and logging/fail helpers; requires .eddi-config and .env; parses COMPOSE_FILES and MongoDB credentials.
MongoDB availability and clearing
gcp/eddi-demo-reset.sh
Verifies mongodb container is running via docker compose ... ps; runs mongosh in the container to deleteMany({}) across a fixed set of EDDI collections and reports per-collection deletion counts.
EDDI restart, health verification, and agent re-import
gcp/eddi-demo-reset.sh
Restarts eddi container, polls http://localhost:$EDDI_PORT/q/health/ready up to 180s for readiness, then POSTs /backup/import/initialAgents and logs 200 vs 409 vs other statuses; exits on fatal errors.
GCP VM provisioning command for reset installation
gcp/provision-vm.sh
Adds install-reset to usage/examples; implements cmd_install_reset to upload eddi-demo-reset.sh, install it at /root/.eddi/eddi-demo-reset.sh, remove legacy cron, and install/enable a systemd oneshot service and systemd timer to run after boot and every 48 hours; adds dispatcher branch.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

  • ginccc

Poem

🐰 I hop a script across the green,
I clear the traces no one’s seen,
I wake the service, wait for cheer,
I seed the agents — all is clear.
Timer ticks, the demo’s clean.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The PR title clearly summarizes the main change: adding a script to reset demo systems via cron or manual execution, which matches the core functionality of the two files added.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feature/delete-demo-instance-content-script

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

@github-actions

github-actions Bot commented Jun 8, 2026

Copy link
Copy Markdown

⚠️ Deprecation Warning: The deny-licenses option is deprecated for possible removal in the next major release. For more information, see issue 997.

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@gcp/provision-vm.sh`:
- Around line 1050-1055: The current systemctl check around "systemctl is-active
--quiet cron" / "crond" only warns and leaves reset scheduling potentially
disabled; change this to remediate or fail: after detecting neither service
active (the block around the systemctl checks), attempt to install the
appropriate package (e.g., cron or cronie depending on distro), enable and start
the corresponding service (cron or crond) via systemctl enable --now, and verify
it became active; if installation/startup fails, exit with a non‑zero status so
the provisioning fails hard. Locate the systemctl checks in the script and
update the else branch to implement install+enable+start for both cron/crond and
a final active verification, otherwise call exit 1.
- Around line 1043-1045: The current cron line uses day-of-month stepping ("0 3
*/2 * *") which doesn't ensure a strict 48-hour interval; replace this with a
systemd timer approach so resets occur strictly every 48 hours. Instead of
writing the cron entry to "$CRON_FILE", create a systemd service unit (e.g.,
eddi-reset.service) that executes ${DEST} and a corresponding eddi-reset.timer
with OnBootSec= and OnUnitActiveSec=48h (or OnCalendar if you prefer a fixed
wall-clock schedule), install/enable the timer, and remove the cron
write/permission lines that reference "$CRON_FILE" to ensure deterministic
48-hour cadence. Ensure the service unit invokes the same command and logs to
/var/log/eddi-reset.log as before.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: ec3a6221-1f7e-4aff-8c3f-d2035a3c4fe6

📥 Commits

Reviewing files that changed from the base of the PR and between 9bb10fd and f0e834a.

📒 Files selected for processing (2)
  • gcp/eddi-demo-reset.sh
  • gcp/provision-vm.sh

Comment thread gcp/provision-vm.sh Outdated
Comment thread gcp/provision-vm.sh Outdated

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
gcp/provision-vm.sh (1)

1086-1086: 💤 Low value

Consider clarifying when the first reset occurs.

The message states "every 48 h" but doesn't explain that the first reset happens 10 minutes after boot (due to OnBootSec=10min on line 1067). If the timer is installed on a VM that has been running for more than 10 minutes, systemd will trigger the reset immediately because the boot time + 10min is already in the past. This is likely acceptable behavior (ensures the timer is working), but documenting it would help set user expectations.

📝 Suggested help text enhancement
-  dim "Runs automatically: every 48 h (systemd timer)"
+  dim "Runs automatically: 10 min after boot, then every 48 h (systemd timer)"

Or, if the immediate-trigger behavior on long-running VMs is undesired, consider using OnActiveSec=10min instead of OnBootSec=10min on line 1067 (triggers 10 minutes after timer is enabled, not after boot).

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@gcp/provision-vm.sh` at line 1086, Update the human-facing timer description
(the dim "Runs automatically: every 48 h (systemd timer)" string) to clarify
when the first reset happens by referencing the systemd unit's OnBootSec=10min
behavior so users know the first run is scheduled 10 minutes after boot (and
will fire immediately if the VM has been up longer than that); optionally note
the alternative OnActiveSec=10min if you prefer the first run 10 minutes after
the timer is enabled instead of after boot.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@gcp/provision-vm.sh`:
- Line 1086: Update the human-facing timer description (the dim "Runs
automatically: every 48 h (systemd timer)" string) to clarify when the first
reset happens by referencing the systemd unit's OnBootSec=10min behavior so
users know the first run is scheduled 10 minutes after boot (and will fire
immediately if the VM has been up longer than that); optionally note the
alternative OnActiveSec=10min if you prefer the first run 10 minutes after the
timer is enabled instead of after boot.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 5146eb1a-6445-4ec8-8de5-30b4ccd82981

📥 Commits

Reviewing files that changed from the base of the PR and between f0e834a and 314da3c.

📒 Files selected for processing (2)
  • gcp/eddi-demo-reset.sh
  • gcp/provision-vm.sh
🚧 Files skipped from review as they are similar to previous changes (1)
  • gcp/eddi-demo-reset.sh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant