feat(cron): add immediate config to control the behaviour on start
#461
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -120,6 +120,9 @@ pub struct Add { | |
| /// Cron retrigger behavior: finish, always, success, fail | ||
| #[clap(long)] | ||
| cron_retrigger: Option<String>, | ||
| /// Trigger cron immediately on first check (default: false) | ||
| #[clap(long)] | ||
| cron_immediate: bool, | ||
|
Comment on lines
+123
to
+125
There was a problem hiding this comment. ❓ Verification inconclusive🏁 Script executed: #!/bin/bash
# Verify that --cron-immediate currently has no declared dependency and is conditionally ignored.
rg -n -C3 'cron_immediate|cron_schedule|PitchforkTomlCron' src/cli/config/add.rsRepository: endevco/pitchfork Length of output: 2203 🌐 Web query:
💡 Result: In the context of the pitchfork CLI (endevco/pitchfork), cron_immediate and cron_schedule are related to the configuration of daemons managed by the tool. Pitchfork allows users to run daemons on a schedule using cron expressions [1]. While the specific identifiers cron_immediate and cron_schedule do not appear as top-level CLI command flags for pitchfork config add, they correspond to components of the cron configuration within the project configuration file (pitchfork.toml) [2][1]. When configuring a daemon with a cron schedule, the full form of the configuration uses a table containing a schedule field [1]: [daemons.example] run = "./script.sh" cron = { schedule = "0 0 2 * * *", retrigger = "finish" } The configuration logic within the pitchfork codebase handles how these schedules are interpreted and executed. Specifically, the supervisor component of pitchfork includes a Cron Watcher that runs at a configurable interval (defaulting to 10 seconds) to check if any cron-scheduled daemons should be triggered [3][4][5]. The retrigger modes (such as finish, always, success, and fail) define how the system behaves if a scheduled task is triggered while a previous execution is still active [1]. Citations:
🌐 Web query:
💡 Result: In the endevco/pitchfork project, cron scheduling is managed via a configuration field in the daemon definition [1]. While the specific file path src/cli/config/add.rs relates to the CLI command used to add new daemon configurations [2], the core logic for cron scheduling relies on a 'cron' field in the pitchfork.toml file [1]. This 'cron' field accepts either a cron expression string (shorthand) or an inline table (full form) containing a 'schedule' parameter [1]. The 'cron_schedule' terminology is explicitly used in the full form configuration, such as in: [daemons.backup] run = "./scripts/backup.sh" cron = { schedule = "0 0 2 * * *", retrigger = "finish" } Although you mentioned 'cron_immediate', Pitchfork's scheduling documentation primarily emphasizes recurring 'cron' expressions and 'retrigger' modes (such as 'finish', 'always', and 'success') to control daemon execution behavior [1]. The system checks for these scheduled tasks at an interval defined by the 'supervisor.cron_check_interval' setting (defaulting to 10 seconds) [3][4]. Citations:
🌐 Web query:
💡 Result: The query “raw.githubusercontent.com endevco pitchfork src/cli/config/add.rs cron_immediate” appears to be looking for Pitchfork source code in endevco/pitchfork (specifically src/cli/config/add.rs) and a symbol/flag named “cron_immediate”. Based on the authoritative sources I found, Pitchfork supports cron scheduling via the daemon configuration field Citations: 🌐 Web query:
💡 Result: The term cron_immediate does not appear to be a standard or public-facing identifier within the endevco/pitchfork project [1][2][3]. While the endevco/pitchfork CLI does provide functionality for managing cron jobs via the pitchfork config add command, its configuration options for cron are documented as --cron-schedule and --cron-retrigger [4]. It is possible that cron_immediate refers to internal source code or a specific private implementation detail within src/cli/config/add.rs that is not exposed in the public documentation or primary API [4][1]. In similar Rust-based scheduling contexts (such as zino-rs), immediate execution flags are sometimes used to run a job immediately upon initialization or scheduling [5][6], but no direct evidence links the specific string cron_immediate to the endevco/pitchfork codebase [4][1][2]. Citations:
🌐 Web query:
💡 Result: The term cron-immediate does not appear to be an official feature, configuration option, or command in the Pitchfork daemon manager [1][2]. Pitchfork is a tool for managing daemons, including support for cron-based scheduling [1][3]. Its documentation defines retrigger modes for cron jobs, which dictate how the supervisor handles a new scheduled run while a previous one is still active [2]. The currently supported retrigger modes are [2]: finish (default): Only triggers a new run if the previous execution has finished [2]. always: Always triggers a new run, stopping the previous one if it is still active [2]. success: Only triggers if the previous execution succeeded (exit code 0) [2]. fail: Only triggers if the previous execution failed [2]. It is possible that "cron-immediate" was a misinterpreted reference to one of these modes (such as "always," which forces execution) or a misunderstanding of how Pitchfork's CLI interface (built with clap) handles task triggering [2][4]. Pitchfork CLI commands are implemented using the Rust clap crate, and interaction with the supervisor is handled via IPC [4][5]. Citations:
🌐 Web query:
💡 Result: The terms "cron_immediate" and "clap(" do not appear as a combined, functional feature within the endevco/pitchfork project [1][2][3]. Pitchfork is a CLI tool for managing daemons and recurring tasks [1][3]. While it does support cron scheduling [1][3] and uses the Rust clap library for its command-line interface [1][3], the specific string "cron_immediate" is not a recognized configuration or command parameter in the project's source code or documentation [1][4][3]. The search results indicate that "cron_immediate" is a parameter used in other software, such as the betterweb/cron Docker container [5], which allows for immediate execution of scheduled jobs. Additionally, "clap(" is a common pattern in Rust codebases when initializing the clap command-line parser [6][7], but it is not a specific identifier associated with a "cron_immediate" feature in pitchfork. If you are seeing these terms in relation to a specific codebase or configuration file, it is possible they originate from a different tool or a misinterpretation of a separate integration [5]. Citations:
Require Pitchfork’s cron CLI/docs describe cron configuration via 🤖 Prompt for AI Agents |
||
| } | ||
|
|
||
| impl Add { | ||
|
|
@@ -217,6 +220,7 @@ impl Add { | |
| Some(PitchforkTomlCron { | ||
| schedule: schedule.clone(), | ||
| retrigger, | ||
| immediate: self.cron_immediate, | ||
| }) | ||
| } else { | ||
| None | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.