-
-
Notifications
You must be signed in to change notification settings - Fork 52
feat: cron based update scheduling #812
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
33 files reviewed, 1 comment
kmendell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm leaving for a trip in a few days, but few things I noticed so far.
- The cron logic in the front and backend is not maintainable , there are libraries out there that can parse cron gocron it self may be able to as well.
Some of the friend logic like normalizing empty inputs can most like be solved by the backed by adding omitempty to. The JSON tags.
I'll try to take a look tomorrow if I have time, but it may be little bit before I can fully review everything.
|
I tried scouring for a good parsing package but everything seems un-maintained or unused so didn't feel confident choosing anything. |
|
@cabaucom376 I made some changes, i use libraries to parse the cron stuff, and teh frontend just had its use a zod schema instead. I also updated the styling to use the existsing styling ofr teh select component vs making a new component for this i though it looked clunky. Ill try to look more later. |
|
Cool, just checked it out. Only thing I'm noticing is that you cannot select immediate and null out the cron expression. |
|
I also did really enjoy the human readable part of it, but if you think its too much thats okay. |
|
The Human Readable part? its still there just not for custom, If we do a human readbale format we get rid of the presets and somehow make universal logic to detect it which is just hard cause id rather not have that done on the fly it could make thinsg feel slow or clunky. |
global cron expression can not be null. It has nothing to inherit from.
| $effect(() => { | ||
| if (cronScheduleMode !== 'custom') { | ||
| $formInputs.autoUpdateCron.value = cronScheduleMode; | ||
| $formInputs.autoUpdateCron.value = cronScheduleMode === null ? '' : cronScheduleMode; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont think this check is needed, 1. im pretty sure it gets set to null anyways and before i chnaged it to hide the text box, it did get set to null. 2. The logic is just messy and not how any of the rest of the data is sent, theres a much easier way to handle this, i just dont have the time to do it right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
35 files reviewed, no comments
| c.JSON(http.StatusInternalServerError, gin.H{ | ||
| c.JSON(http.StatusBadRequest, gin.H{ | ||
| "success": false, | ||
| "data": dto.MessageDto{Message: "Failed to update settings"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be the data field as the frontend services apiserver this.handleReponse will grab from the data field
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think adding some e2e test for setting the settings of a project will be useful, that way if functionaltiy breaks we will know.
| .updateSettings(data) | ||
| .then(() => toast.success(m.navigation_settings_saved())) | ||
| .catch((error) => { | ||
| .catch((error: any) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my comment about the data field above, for all of this : any types. This should not be needed since it was all working with the "data" field.
| composeContent, | ||
| envContent | ||
| }; | ||
| const payload: any = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This logic is overkill, we should aollow the same pattern as before, the backend should just send empty values if its not set.
Replace the interval-based auto-update system entirely with a cron-based scheduler that supports:
com.ofkm.arcane.updaterlabelcloses #491
Disclaimer Greptiles Reviews uses AI, make sure to check over its work
Greptile Overview
Updated On: 2025-11-03 13:27:39 UTC
Greptile Summary
This PR successfully replaces the interval-based auto-update system with a comprehensive cron-based scheduler that addresses issue #491.
Key Changes
autoUpdateCronsetting replaces the old interval-based system, supporting standard 5-field cron expressions validated by the robfig/cron libraryauto_update(nullable boolean) andauto_update_cron(nullable string) to override global settings, providing fine-grained controlcom.ofkm.arcane.updaterlabel is automatically injected into containers based on project settings, allowing per-service controlImplementation Quality
The implementation is well-structured with proper separation of concerns:
cron_util.go)Confidence Score: 5/5
Important Files Changed
File Analysis
autoUpdateCronsetting at line 320-323, triggers reschedule callback on changeautoUpdateCronat line 791-794, passes project settings to LoadComposeProjectcom.ofkm.arcane.updaterbased on project AutoUpdate setting