Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Job integer frequency (run job every Nth webchanges run) #52

Open
drws opened this issue Dec 29, 2022 · 2 comments
Open

[FEATURE] Job integer frequency (run job every Nth webchanges run) #52

drws opened this issue Dec 29, 2022 · 2 comments

Comments

@drws
Copy link

drws commented Dec 29, 2022

Is your feature request related to a problem? Please describe.
Some jobs need more checks than others (per time interval), which is impossible to achieve with a single webchanges instance.

Describe the solution you'd like
A simple parameter that allowed a job to skip some runs would suffice to achieve different time periods. By analogy the parameter could also be called gear. If gear of the job is 1, it runs every time, second-gear jobs run every second time, and so on.

Describe alternatives you've considered
Multiple instances of webchanges. Works, but is not a clean solution.

Additional context
There's only a single job counter needed to implement this. However, this request also poses an opportunity to discuss whether each job should have its own counter (for some other reason).

@yubiuser
Copy link

yubiuser commented Dec 4, 2023

Why don't you use two cron jobs on two jobs.yml with different execution frequencies?

@drws
Copy link
Author

drws commented Dec 12, 2023

Why don't you use two cron jobs on two jobs.yml with different execution frequencies?

As explained in the OP:

Describe alternatives you've considered
Multiple instances of webchanges. Works, but is not a clean solution.

So... multiple cron entries and multiple points of failure, fragmented configuration, repetitious commands... It's usually not hard to work around bugs with solutions such as multiple instances, but these aren't proper fixes, merely workarounds.

Let me also reinstate that there's only a single global job counter needed to implement this and a runtime one at that (RAM-bound that resets upon OS restart). So not even additional flash write cycles are needed for this feature to operate.

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

No branches or pull requests

2 participants