Skip to content

fix: run_all() takes settings explicitly, matching the other pipeline modules - #31

Merged
codeapplied merged 1 commit into
mainfrom
fix/run-daily-settings-consistency
Sep 1, 2026
Merged

codeapplied merged 1 commit into
mainfrom
fix/run-daily-settings-consistency

Conversation

@codeapplied

Copy link
Copy Markdown
Owner

Closes #28.

run_all() (pipeline/run_daily.py) previously read the global config.settings singleton directly, unlike sync_pipedrive()/sync_calendar()/reconcile(), which all take settings as an explicit parameter. Now consistent: run_all(settings, apply=False).

This wasn't just a style inconsistency — it was a real testability gap: run_all() couldn't be tested in isolation before this without either mutating the global singleton (which scripts/generate_readme_assets.py had to do) or bypassing it entirely and testing run_source() directly (which is what the existing test suite did). cli.py's run() command updated to pass its own settings through explicitly, same pattern it already uses for the other sync commands.

Added 3 new tests for run_all() itself — dry-run vs apply, disabled portals skipped — proving the fix actually closes the testability gap, not just refactoring for its own sake; these literally could not have been written cleanly against the old signature.

Verified: 59/59 tests pass; smoke-tested tendertracker run and run --apply end-to-end, unchanged behavior.

@codeapplied
codeapplied merged commit d359918 into main Sep 1, 2026
1 check passed
@codeapplied
codeapplied deleted the fix/run-daily-settings-consistency branch September 1, 2026 07:41
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.

run_daily.py: settings/config-path inconsistency

1 participant