Page MenuHomePhabricator

Publish branch lint information into Fact
AbandonedPublic

Authored by hach-que on May 15 2014, 6:42 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Apr 29, 2:05 PM
Unknown Object (File)
Wed, Apr 24, 9:56 PM
Unknown Object (File)
Tue, Apr 23, 9:23 AM
Unknown Object (File)
Sun, Apr 21, 4:20 PM
Unknown Object (File)
Apr 3 2024, 3:56 PM
Unknown Object (File)
Apr 1 2024, 6:06 AM
Unknown Object (File)
Mar 29 2024, 2:55 AM
Unknown Object (File)
Mar 10 2024, 4:29 PM

Details

Summary

This uses a Fact engine that operates on PhabricatorRepositoryBranch to report historical information into Fact.

Notable changes are:

  • fact_raw and fact_aggregate gained a stringA field, which is used to store a grouping / filtering string value against facts (used for paths in this case).
  • PhabricatorRepositoryBranch gained a PHID, which is used so we can store facts against a branch.
  • The string value can be filtered on through the Fact UI.

The rest of it was pretty straight forward in terms of emitting facts from the engine. The only remaining problem is that Fact by default removes old raw entries for objects before updating them; in the case of branches we actually want to keep older entries. Since there didn't seem to be a simple way of specifying this in the architecture, I need feedback on how to tackle this issue.

Test Plan

Ran builds that created lint information, used bin/fact analyze to emit facts into Fact. Browsed and filtered in the UI based on file paths.

Event Timeline

hach-que retitled this revision from to Publish branch lint information into Fact.
hach-que updated this object.
hach-que edited the test plan for this revision. (Show Details)
hach-que added a reviewer: epriestley.
hach-que edited edge metadata.

Fixed lint warnings

Prevent crash when migrating multiple branches

src/applications/fact/daemon/PhabricatorFactDaemon.php
217–218

This needs to change somehow; stringA isn't considered to be part of a key so when the aggregated values of each path get added, they get overwritten.

Is the best course of action here just to change the unique key on the table to include stringA?

Abandoning this because Fact is still very far away on the upstream roadmap, and by the time upstream work starts on it, this will probably be out-of-date anyway.