-
Notifications
You must be signed in to change notification settings - Fork 142
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
Allow for recurring maintenance events #246
base: master
Are you sure you want to change the base?
Conversation
if (metadata.expectedDown) | ||
expectedDegraded = metadata.expectedDown | ||
.split(",") | ||
.map((i) => i.trim()) | ||
.filter((i) => i.length); |
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.
Additionally this PR I fixed the expectedDegraded
array. You can see here we were actually just checking expectedDown
twice, and assigning it to expectedDegraded
}); | ||
console.log("Closed maintenance completed event", incidentNumber); | ||
} | ||
|
||
export const update = async (shouldCommit = false) => { |
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 observed that if an error is thrown at all throughout this process, we fail the GitHub Action and dont raise any alerts.
If someone misconfigures a maintenance issue, they could inadvertently disable all of their uptime checks. This probably warrants a separate issue and fix, regardless of how this PR goes.
Hello! This PR allows for creating recurring maintenance events utilizing the RRule iCalendar string format.
This feature was requested here https://github.com/orgs/upptime/discussions/787
Implementation
To support recurring maintenance, we allow users to provide an
rrule
andduration
in addition to the existing properties on a maintenance issue.With the
rrule
andstart
properties, we can determine each moment that a maintenance event is expected to start, and withduration
, we can tell how long each event will be.The
end
date functions only as the marker for when the maintenance issue should be closed.Reasoning
I opted to go with this approach as the RRule rfc allows for a lot of flexibility, and there are already tools and libraries that support parsing and generating the string. This seemed more optimal than trying to create our own syntax for recurring maintenance.
I'm happy to change the implementation and talk further if you have other ideas in mind.
Example
An example rrule is
FREQ=DAILY;INTERVAL=2
, which declares the event occurs every other day. I've been using this demo app to create these rrules and test with them https://jkbrzt.github.io/rrule/The duration supports units of minutes, hours and days. The expected format is
{NUMBER}{UNIT}
, for example,20M
,12H
, and3D
So an example daily maintenance issue, that lasts 15 minutes, and never stops recurring, would looks something like this
Dependencies and other notes
With this PR I added this JS library for parsing RRules https://github.com/jkbrzt/rrule, and I utilize the utc dayjs plugin to ensure we can support timezones in the ISO strings. (The RRule library expects dates to be in UTC)
Documentation still needs to be written.
Also I apologize for the commit history, I was struggling to package this and use it in my own github actions for testing :)
Thanks! Let me know your thoughts