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

Allow for recurring maintenance events #246

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

Sheemap
Copy link
Contributor

@Sheemap Sheemap commented Apr 1, 2024

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 and duration in addition to the existing properties on a maintenance issue.

With the rrule and start properties, we can determine each moment that a maintenance event is expected to start, and with duration, 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, and 3D

So an example daily maintenance issue, that lasts 15 minutes, and never stops recurring, would looks something like this

<!--
start: 2024-02-30T04:00:00-00:00
rrule:FREQ=DAILY
duration: 15m
expectedDown: down-service
expectedDegraded: degraded-service
-->

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

Comment on lines -88 to -92
if (metadata.expectedDown)
expectedDegraded = metadata.expectedDown
.split(",")
.map((i) => i.trim())
.filter((i) => i.length);
Copy link
Contributor Author

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) => {
Copy link
Contributor Author

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.

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

Successfully merging this pull request may close these issues.

1 participant