Implement Chronicle v0.9
AbandonedPublic
Actions

Authored by hach-que on Jun 20 2014, 4:56 AM.

Details

Reviewers

epriestley

Group Reviewers

Blessed Reviewers

Maniphest Tasks

T5207: Implement Chronicle

Summary

Resolves T5207. This implements Chronicle to a point where it works and you can trigger Harbormaster builds on a scheduled basis. It probably still needs some usability improvements before people can generally use it (in particular, the UI for editing the period on which the trigger fires is just a JSON blob).

It's currently hidden from the launcher and marked as beta.

Test Plan

Tested everything and it worked.

Diff Detail

Repository

rP Phabricator

Branch

chronicle1

Lint

Lint Passed

Severity	Location	Code	Message
Advice	src/applications/chronicle/application/PhabricatorApplicationChronicle.php:46	XHP16	TODO Comment
Advice	src/applications/chronicle/controller/ChronicleTriggerEditController.php:139	XHP16	TODO Comment
Advice	src/applications/chronicle/query/ChronicleTriggerSearchEngine.php:30	XHP16	TODO Comment

Unit

No Test Coverage

Build Status

Buildable 1259
Build 1259: [Placeholder Plan] Wait for 30 Seconds

Event Timeline

hach-que updated this revision to Diff 23125.Jun 20 2014, 4:56 AM

hach-que retitled this revision from to Implement Chronicle v0.9.

hach-que updated this object.

hach-que edited the test plan for this revision. (Show Details)

hach-que added a reviewer: epriestley.

hach-que added a task: T5207: Implement Chronicle.

Herald added a reviewer: Blessed Reviewers. · View Herald TranscriptJun 20 2014, 4:56 AM

Herald added subscribers: Korvin, epriestley. · View Herald Transcript

Harbormaster completed remote builds in B1259: Diff 23125.Jun 20 2014, 4:57 AM

D11419 implements an alternative piece of drive infrastructure which is better suited for other applications we want to pursue. It's a bit more low-level than this.

A couple of notes about differences in design inline. It doesn't have any UI and probably only overlaps with about 20% of this diff (basically, the daemon part).

I don't have any plans to upstream this anytime soon, just kicking it back to you since there's at least some relevant upstream progress now and I looked through it in writing D11419.

src/applications/chronicle/action/ChronicleAction.php
3	Major difference here is that trigger actions do as little work as possible (they are strongly encouraged to queue a worker task instead of executing any logic), to make it as hard as possible to ever overload the daemon. This could use that model by having a thin trigger action which queues a task to execute a Chronicle action, though.
src/applications/chronicle/daemon/ChronicleDaemon.php
38–57	This is the biggest difference in the two designs: this approach has a huge race window, up to 65 seconds + time it takes to execute the trigger, which may be long. If a user modifies the trigger during these 65+ seconds from the web UI, their changes will be lost after the trigger executes and calls `save()`, overwriting the trigger and reverting it to a state it was in 65 seconds ago. There's also a small race window at the end where a user can load, the daemon saves, then the user saves. In this case, the event will execute twice. That's OK for builds, but not good for email notifications and catastrophically bad for billing. D11419 has more complicated infrastructure, but I believe it prevents the daemon from ever racing against the application.