add script to reset demo systems via cron or manually - #522
Conversation
📝 WalkthroughWalkthroughAdds 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). ChangesDemo Reset Automation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
There was a problem hiding this comment.
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
📒 Files selected for processing (2)
gcp/eddi-demo-reset.shgcp/provision-vm.sh
There was a problem hiding this comment.
🧹 Nitpick comments (1)
gcp/provision-vm.sh (1)
1086-1086: 💤 Low valueConsider 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=10minon 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=10mininstead ofOnBootSec=10minon 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
📒 Files selected for processing (2)
gcp/eddi-demo-reset.shgcp/provision-vm.sh
🚧 Files skipped from review as they are similar to previous changes (1)
- gcp/eddi-demo-reset.sh
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
Related Issue
Closes #
Changes Made
How to Test
Checklist
./mvnw clean verify -DskipITs)Summary by CodeRabbit