Extract cron schedule registration out of runServeCmd#47562
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (2)
WalkthroughRefactors cron schedule registration by moving inline registration from cmd/fleet/serve.go into a new cmd/fleet/cron_registration.go. Introduces cronSchedulesDeps and startCronSchedules which call domain-scoped registration helpers (cleanup/maintenance, vulnerabilities, worker, MDM, premium, miscellaneous). serve.go now calls startCronSchedules with the consolidated deps, unused imports were removed, and tracing.StartSettingsPoller is started earlier. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
cmd/fleet/cron_registration.go (1)
62-68: 🏗️ Heavy liftAdd a regression test around the orchestrator order and gates.
startCronSchedulesis now the single entry point for 30+ conditional registrations, but this refactor still relies on manual verification that helper order and gating match the old inline flow. A small recorder aroundCronSchedules.StartCronSchedulewould make future edits here much safer.🤖 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 `@cmd/fleet/cron_registration.go` around lines 62 - 68, Add a regression test that verifies the orchestrator order and gating in startCronSchedules by creating a test double for CronSchedules whose StartCronSchedule method records each registration call (name/identifier and any gate-relevant params), then call startCronSchedules with controlled deps toggling the various gates and assert that the recorded sequence matches the expected order of helper registrations (registerCleanupAndMaintenanceCrons, registerVulnerabilityCrons, registerWorkerCrons, registerMDMCrons, registerPremiumCrons, registerMiscCrons) and that gated registrations only occur when their deps permit; implement assertions for both full-enabled and selectively-disabled gate permutations to catch regressions.
🤖 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 `@cmd/fleet/cron_registration.go`:
- Around line 62-68: Add a regression test that verifies the orchestrator order
and gating in startCronSchedules by creating a test double for CronSchedules
whose StartCronSchedule method records each registration call (name/identifier
and any gate-relevant params), then call startCronSchedules with controlled deps
toggling the various gates and assert that the recorded sequence matches the
expected order of helper registrations (registerCleanupAndMaintenanceCrons,
registerVulnerabilityCrons, registerWorkerCrons, registerMDMCrons,
registerPremiumCrons, registerMiscCrons) and that gated registrations only occur
when their deps permit; implement assertions for both full-enabled and
selectively-disabled gate permutations to catch regressions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d923fb08-f6dd-4200-975e-8eaceec6dea3
📒 Files selected for processing (2)
cmd/fleet/cron_registration.gocmd/fleet/serve.go
raju249
force-pushed
the
33370-cron-registration-extraction
branch
from
fa0e5a0 to
17fb140
Compare
Move the 33 StartCronSchedule registrations into a new cmd/fleet/cron_registration.go, grouped by domain (cleanup/maintenance, vulnerabilities, workers, MDM, premium, misc) and driven by a cronSchedulesDeps struct. runServeCmd builds the struct once and makes a single startCronSchedules call; registration order and arguments are preserved exactly. Extract the vuln enable/disable decision into vulnerabilityProcessingDisabled and unit-test it (covers the legacy current_instance_checks "0" value). Refs fleetdm#33370
raju249
force-pushed
the
33370-cron-registration-extraction
branch
from
17fb140 to
4216ea1
Compare
|
Hello @MagnusHJensen - I am slicing the cron related code out of serve.go - For context on the structure: the domain-grouped Would you be able to take a review, please? And let me know wdyt of the approach forward for other cron extractions. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #47562 +/- ##
==========================================
- Coverage 67.19% 67.17% -0.03%
==========================================
Files 3616 3617 +1
Lines 229016 229057 +41
Branches 11785 11785
==========================================
- Hits 153885 153858 -27
- Misses 61303 61360 +57
- Partials 13828 13839 +11
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
1 participant
Extracts the cron schedule registration out of
runServeCmdand into a newcmd/fleet/cron_registration.go. Same pattern as the prior extractions on this issue (#44929, #45343, #45583, #46166, #46421, #46517, #46742, #46830, #46893, #47151). This is the largest slice so far —runServeCmddrops from ~1300 to ~1000 lines, andserve.gofrom 1776 to 1472.The 33
StartCronScheduleregistrations move into onestartCronSchedulesentry point backed by acronSchedulesDepsstruct (the dependencies the closures previously captured fromrunServeCmd). Registration is grouped by domain:registerCleanupAndMaintenanceCrons— chart data collection, thecron_statscleanup goroutine, software migrations, frequent cleanups, cleanups-then-aggregation, query results cleanup, upcoming activities, usage statistics, batch activities.registerVulnerabilityCrons— the vulnerabilities schedule, or the remote-trigger proxy when processing is disabled on this instance.registerWorkerCrons— automations and worker integrations.registerMDMCrons— Apple MDM worker, DEP profile assigner, service discovery, the Apple/Windows/Android profile managers, the Android device reconciler, the Android policy migrations, and the APNs pusher.registerPremiumCrons— iPhone/iPad refetcher and reviver, maintained apps, VPP app version refresh (and the one-shot VPP country backfill), recovery lock passwords, managed local account rotation, activities streaming, and the calendar schedule.registerMiscCrons— host vitals label membership and the batch activity completion checker.Behavior is preserved — the schedules register in the same order with the same arguments, the same conditionals gate them (premium, audit log, env vars, software store presence), and the
configis threaded as a pointer so the&configandconfig.Calendarmutations inside the calendar closure keep their original semantics.cmd/fleet/cron.go(the schedule definitions) is intentionally untouched; only the wiring moved.One unit test added:
TestVulnerabilityProcessingDisabledcovers the vuln enable/disable predicate extracted intovulnerabilityProcessingDisabled, including the legacycurrent_instance_checks"0"value. The rest of the file is dependency-wiring relocation with no further decision logic to unit-test — those paths construct real schedules, so they stay covered by the existing suite and integration tests. The fullcmd/fleetsuite passes against MySQL + Redis, and a local server boot confirms the same 30 cron schedules start as before (verified against the "started cron schedules" log line).Related issue: Refs #33370
Checklist for submitter
Summary by CodeRabbit
Refactor
New Features / Behavior
Tests