-
Notifications
You must be signed in to change notification settings - Fork 117
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
Scheduler API #89
Scheduler API #89
Conversation
Codecov Report
@@ Coverage Diff @@
## master #89 +/- ##
=========================================
Coverage ? 54.94%
=========================================
Files ? 70
Lines ? 2448
Branches ? 362
=========================================
Hits ? 1345
Misses ? 1103
Partials ? 0
Continue to review full report at Codecov.
|
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.
Looks quite nice to me, though very dependent on later. The interfaces and types look well designed. The biggest headache to me is i18n.
src/definition/scheduler/Schedule.ts
Outdated
} | ||
|
||
export class Schedule implements ScheduleData { | ||
public static fromText(text: string): 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.
ahh, now seeing you included the factory method here. Then, two questions:
- Why did you integrated it into the actual
Schedule
(and not a separate factory, except laziness ;) )? - Why did you have this wrapped in the JobBuilder as well?
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.
- So people can easily generate a schedule outside of the builder.
- Makes the builder an all-in-one, trying to make things easy for developers.
@graywolf336 is this preventing the jib to run multiple times when running rocket.chat in a cluster? |
@graywolf336 do you think this needs to be defined only inside the configuration method? Would be nice to define cron jobs based on messages or slashcommands, I think this should be something in the app class context. |
@rodrigok Yes, it will only run the job once even when there are multiple instances of the App system running. And it will be available to Apps all the time, not just at initialization time. There is still a lot of work to do, hence the "in progress" label. The reason this pull request was created was to get feedback from people, such as what @mrsimpson provided. 🙂 |
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.
Looking forward to this being implemented! Would be very useful.
import { IJob } from '../scheduler'; | ||
import { IJobBuilder } from './IJobBuilder'; | ||
|
||
export interface ISchedulerExtend { |
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 this interface is missing some features.
You want to be able to unschedule jobs and get a list of scheduled jobs
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.
So, what I'm going to do is add a new accessor to to the modify stage to allow modification to the jobs. But if I get into it and that is not a fluid design or works in reality, then we will see how else we can work with this.
@graywolf336 Is there anything I can do to help you work on this feature? I'm not very familiar with the apps-engine (only played around a bit with creating an app), but I'm willing to dedicate some time to help you work on this. |
@dbrekelmans hey! nice to know you're interested in helping us with this! We're bringing this back up in our queue and will be dedicating time to the feature in the following weeks, and would definitely appreciate the help! We've updated the description to reflect what is still missing to get this published :) |
Also, we switched to only supporting crontab style scheduling as of right now. In the future we may support a form of i18n scheduling. This decision was reached after we decided we wanted this feature out now instead of another year from now (aka two years after the feature was first attempted).
* user friendly since the list of job names will be visible | ||
* to the server administrator. | ||
*/ | ||
name: string; |
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.
Thoughts to everyone watching this thread about requiring an id: string
property? As right now the name: string
is simply for displaying on the UI the list of jobs and a history of them. But if an App wants to cancel a job or view the job's history there is not a way to do it currently. My idea is to allow the App to define the property but if the app leaves it empty then a random one will be generated.
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.
Couldn't we use the name for that? Prepend it with the appId
and a colon and should be good to go IMO 😛
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.
For our internal usage, yes. But for Apps to query, no. Because what if they want the same name for a job that runs based upon something a user does but doesn't want that detail to show up in the job history and they want to query all of the jobs done by a user? That's why I'm considering an id..
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.
Because what if they want the same name for a job that runs based upon something a user does but doesn't want that detail to show up in the job history and they want to query all of the jobs done by a user?
I'm not sure I quite understand what you mean by this. Could you maybe give a small example?
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.
Let's say you only want one job to run but you have two internal jobs and their behavior is massively based upon a configuration. The setting is changed in the admin area and when that happens you want to replace the job, that way the admin isn't aware of the different types and only sees one job in the job history and that type of stuff. Does that make sense?
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 don't understand why there would be one job running multiple internal jobs. Shouldn't that just be separate jobs then?
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.
Imagine a payroll or something. For auditing purposes there should only appear as one job in the log. But because payroll is an extremely complicated item, the developer wants to separate the logic out from one giant job into different ones. So internally there are several jobs by the same name that way it appears as one job. I know this is an example that is stretching it, but I do see some valid reasons for not having the name be unique.
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.
gotta admit I didn't follow the use case either :/
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 I understand what @graywolf336 means.
IMO if an app wants to split one scheduled job into multiple parts, then that's something the app itself can solve and not something that should be solved by the scheduling API
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.
And that's why I'm think we probably should have an id for the jobs and not rely on the name 🤔
@@ -0,0 +1,35 @@ | |||
import { parseExpression } from 'cron-parser'; |
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.
Hey @d-gubert, I'm still interested in helping, but I'd need something concrete to work on. Maybe we can find something tomorrow. I just joined open.rocket.chat, so we could chat there if you'd like. I'm definitely going to write a remind-me app once this API is available. If it's up to standards maybe it could serve as an example for people looking to use this API. |
@dbrekelmans what's your username on the oepn.rocket.chat server? |
@graywolf336 it's |
Any progress on this? I need it desperately. The lack of a scheduler API is the last thing blocking me from completing a daily standup application for Rocket.Chat (like standup-raven for Mattermost), which in turn is the last bit I need to migrate the entire company to Rocket.Chat. |
@sveatlo can you try out the current code base and get a feel for deploying an App using the current API? Then provide us feedback on it and ways we can improve? |
Any progress? |
I am looking forward to it :D |
Closing this out dated PR in favor of the new functionality that has been in the Apps Engine for a while now. :) |
To Do list:
later
is no longer active)