-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Refactor Cron and merge dashboard tasks #10745
Conversation
* Merge Cron and Dashboard tasks * Make every cron task report a system notice on completion * Refactor the creation of these tasks * Ensure that execution counts of tasks is correct * Allow cron tasks to be started from the cron page
This PR still not resolve the probblem that multiple gitea instances will run tasks duplicated. |
@lunny I guess you mean if you have a cluster of giteas you only want one task running on one gitea at a time? I think that would need a DB flag? |
Handling aborts properly is a problem in such a unique queue. Is Gitea currently prepared for multi-instance setups, or we're just trying to be future proof? Because if the later is true, we could just implement better queue implementations in future PRs. |
@zeripath Out topic. My idea is we need a cluster mod, that there will be an etcd to store all the gitea servers information and one will be elected as master. Then only one instance(master) will create the cron task when the time is in. But the tasks will be queued, so that the tasks will be handled by all the gitea servers load balance. For a standalone mode, only a master node, it will produce tasks when the time in and handle the tasks itself. There is no DB flag, because all instances will have the shared DB data. But the tasks could be stored in database |
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.
Wow! It was intimidating, but not as hard to review as I thought. 😅
Just some items to clarify. It looks very good! 🎉
|
||
if config.IsEnabled() { | ||
// We cannot use the entry return as there is no way to lock it | ||
if _, err = c.AddJob(name, config.GetSchedule(), task); err != nil { |
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 guess this will not duplicate or re-schedule tasks registered from previous instances (like those with @anually
schedule). 😶
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.
TBH we need a database backend for these "@annually" scheduled tasks. That probably involves us either bringing cron in to Gitea or forking it.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Signed-off-by: Andrew Thornton <art27@cantab.net>
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.
Just one nit, non blocking. LG-TM.
Codecov Report
@@ Coverage Diff @@
## master #10745 +/- ##
==========================================
+ Coverage 43.84% 43.89% +0.05%
==========================================
Files 607 611 +4
Lines 86893 87207 +314
==========================================
+ Hits 38098 38283 +185
- Misses 44093 44206 +113
- Partials 4702 4718 +16
Continue to review full report at Codecov.
|
@lafriks can you review again? |
I think we can create a timer events source to create tasks to queue and reuse our old queue style. |
@lunny Mostly that's orthogonal to this work. We'd need a different type of unique queue, one that leaves the item in the set until it's been processed. It's possible - we'd need to sort adjust the handler to remove the item as a defer after handling. But as I say that's mostly orthogonal to these changes. |
@lunny do you have any further comments? |
@zeripath should we move this to 1.13 also? |
Unlike the other one I moved to 1.13 this is far less likely to cause problems. I think it'd be a shame for this not to get in to 1.12. |
I prefer this to get into 1.12 as well |
🚀 |
After go-gitea#10745 was merged, the number of System Notices increased obviously. Add the type filter is useful to help users to quickly check out the useful message they want. Signed-off-by: a1012112796 <1012112796@qq.com>
The GC isn't working in the 1.12.0 release. |
@somera can you create a new issue - referencing old pulls/issue is the way to go - but dont append new stuff to closed/merged one :) |
Unfortunately go-gitea#10745 merged a spurious logging message. This PR removes this. Signed-off-by: Andrew Thornton <art27@cantab.net>
Unfortunately #10745 merged a spurious logging message. This PR removes this. Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: Lauris BH <lauris@nix.lv>
Backport go-gitea#12139 Unfortunately go-gitea#10745 merged a spurious logging message. This PR removes this. Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: Lauris BH <lauris@nix.lv>
* Refactor Cron and merge dashboard tasks * Merge Cron and Dashboard tasks * Make every cron task report a system notice on completion * Refactor the creation of these tasks * Ensure that execution counts of tasks is correct * Allow cron tasks to be started from the cron page * golangci-lint fixes * Enforce that only one task with the same name can be registered Signed-off-by: Andrew Thornton <art27@cantab.net> * fix name check Signed-off-by: Andrew Thornton <art27@cantab.net> * as per @guillep2k * as per @lafriks Signed-off-by: Andrew Thornton <art27@cantab.net> * Add git.CommandContext variants Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: Lauris BH <lauris@nix.lv> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Unfortunately go-gitea#10745 merged a spurious logging message. This PR removes this. Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: Lauris BH <lauris@nix.lv>
Fix #10299