Page MenuHomePhabricator

Implement Chronicle
Closed, InvalidPublic


Chronicle is an application for triggering actions on time-based events. It is mainly intended to be used to trigger Harbormaster builds (but can be used for other things in the future).

Chronicle trigger table:

  • id
  • phid
  • name
  • epoch
  • repeat
  • actionClass
  • actionData

Action implementations will need custom field support and should be reasonably similar to how build steps are configured.

Revisions and Commits

Event Timeline

hach-que claimed this task.
hach-que raised the priority of this task from to Needs Triage.
hach-que updated the task description. (Show Details)
hach-que added a project: Harbormaster.
hach-que added subscribers: hach-que, epriestley.

I'm not sure exactly what this will look like in the upstream. I think the task scheduling infrastructure will almost certainly come upstream in some form, at a minimum to support use cases like:

  • Send a notification 15 minutes before a Calendar event.
  • Bill a subscription on the 28th.

D9637 mostly focuses on building UI. I'm not yet sold on this being a very compelling use case, and plan to address at least some of the Harbormaster integrations largely in more specific ways (e.g., "run when master changes" instead of "run every 15 minutes").

Overall, I want to wait on this until I have a clearer vision of where we're taking it. I'd guess what lands will be a little lighter on UI and a little heavier on infrastructure.

The general shape of D9637 seems reasonable. I think a dedicated daemon is probably correct, although it might be able to merge with the GC daemon (which is essentially a hard-coded cron script). I would guess that it also needs to execute stuff in the task queue instead of in-process. We can provide stronger assurances of timeliness now that the task queue supports explicit priorities, which I don't think it did when this was written.

The primary reason for UI focus was that I imagined people using this like Herald. Instead of setting up "build on commit" rules in Harbormaster, those are configured in Herald.

But maybe this assumption is wrong for timed events, and that each application using this infrastructure will expose registering timed events in their own way (so Harbormaster plans would have an "Edit Schedules" page or something of that nature). Given how clunky the UI feels in Chronicle at the moment, that could be better or worse, depending on whether the underlying reason is configuring Chronicle rules like this is a bad idea, or due to the lack of a proper scheduling UI control that allows easy configuration of different epoch types. Certainly in the two use cases above, no scheduling UI control is needed, so potentially this is specific to Harbormaster as well.

Pursue using the infrastructure in D11419 instead.