Page MenuHomePhabricator

Replace Harbormaster "BuildItem" with Lint/Unit messages
ClosedPublic

Authored by epriestley on Jun 17 2015, 2:30 PM.
Tags
None
Referenced Files
F18835846: D13329.diff
Sun, Oct 26, 7:25 PM
F18810824: D13329.id.diff
Sun, Oct 19, 11:38 PM
F18806831: D13329.diff
Sat, Oct 18, 9:45 PM
F18783232: D13329.id32386.diff
Mon, Oct 13, 5:08 AM
F18778236: D13329.id32249.diff
Sat, Oct 11, 8:37 AM
F18635161: D13329.diff
Sep 17 2025, 12:46 AM
F18498425: D13329.diff
Sep 4 2025, 6:42 PM
F18462220: D13329.diff
Sep 1 2025, 9:50 PM

Details

Summary

Ref T8095.

Harbormaster has a BuildItem class, but it has no table and is unused. This was an earlier idea about representing lint/unit results and some other possible types of messages, but I think we want to be more specific than this.

Remove BuildItem and add Lint and Unit storage. These tables roughly parallel how we store lint/unit messages today, with some guesses about how where they'll go in the future.

Test Plan

Ran bin/storage upgrade and got a clean adjust out of it.

Diff Detail

Repository
rP Phabricator
Branch
plan1
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 6828
Build 6850: [Placeholder Plan] Wait for 30 Seconds

Event Timeline

epriestley retitled this revision from to Replace Harbormaster "BuildItem" with Lint/Unit messages.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: btrahan.
btrahan edited edge metadata.
btrahan added inline comments.
resources/sql/autopatches/20150617.harbor.1.lint.sql
7–8

Depending on how much re-design wiggle room you have here, perhaps "code" can also encompass "severity"?

This revision is now accepted and ready to land.Jun 17 2015, 10:31 PM

For reference, this will conflict with D11692, which will need to be updated to use these new storage classes.

This revision was automatically updated to reflect the committed changes.

I think it's desirable that "severity" remain separate from "code". In some projects a message with the same code (say, something like some sort of whitespace issue) might be a "warning", while in others it might only be "advice". It seems reasonable to let projects configure how much they care about each kind of issue lint can raise.