Page MenuHomePhabricator

Plans: Harbormaster UI usability and interconnectedness
Open, NormalPublic


See PHI351. An install has 256+ character unit test names. I think this essentially always a problem before the data hits Phabricator (i.e., these names aren't useful to humans, either) but this is probably a case where we should give installs enough rope to shoot themselves in the foot. See also T11402, which discusses the total size of the test table. I expect that extracting these strings to a dimension table likely makes sense, with some absurd soft limit (like 1MB) to forestall disaster when an install uploads a unit test with a 750MB name and every interface becomes mysteriously slow.

General questions about "which specific tests are failing" which storage changes should support:

  • T9365 is probably related but needs triage.
  • Same with T12029.
  • This gets a mention in PHI383.
  • T9951 wants this storage to have a basket of random properties. Maybe? This tends to make archival/storage more difficult but doesn't seem unreasonable.
  • T10123 is probably some aggregation of other stuff here.
  • See also T11763.

T10635 is perhaps adjacent although I'm not sure what the current state of it is.

From PHI383:

What unit tests have recently failed? ... On which buildables?
What build plans have failed recently? ... On which buildables?
What build steps have failed recently? ... On which buildables?
What builds are running right now against buildables of this type?

You can get some of this in the UI but it's very scattered. These are all largely reasonable questions to ask. Harbormaster doesn't do a good job of showing an overall "state of the world in builds" status dashboard or giving you the components to build one today.

What builds are running right now? What builds are running of a given plan?

These can be answered at /harbormaster/build/ but it (or some other interface) could be better at answering questions instead of just presenting information.

[ Which Drydock resources have had unit test, plan and step failures recently? ]
What builds are running within a given [Drydock] resource pool?
What builds has this drydock resource/resource pool had run on it? What build plans? What tests have failed on it?

These are likely reasonable but the path is currently a little muddier since Harbormaster/Drydock have little explicit bridging today.

See PHI405. This task discusses some reasonable improvements to the Harbormaster/Differential integration.

See PHI446. This task discusses providing ways to access older builds and build logs instead of vanishing them from the UI completely. (This works now, but it would be nice to make the UI a little richer.)

See PHI430. Policy exceptions raised while rendering "Build Status" are currently not handled as well as they could be.

See PHI507. An install would like better support for richer build artifacts, particularly screenshots.

See T10568. The checkmark icon tooltip in Diffusion for builds could be more useful on failures, e.g. "3/5 builds passed" or, more likely, break out which builds failed.

In T13124 / PHI531, I'm introducing a "magic" step ("Abort Older Builds") which applies before the build actually starts. If this sticks:

  • It should probably be called out in the UI.
  • It shouldn't be able to generate artifacts or depend on other steps.
  • It should either skip target generation entirely, or generate an empty target, and then immediately re-enter the build update. Currently, we'll return to the queue to execute an empty step which does nothing.
  • T13072 should happen, and BuildCommand needs to stop being transactional; it can currently race.
  • Also, this whole thing might be a bad idea.
  • It should possibly issue a special build command like "Render Obsolete", not "Abort".
  • Long-running steps, like "Sleep" and "Drydock: Run Command", should test for build aborts while sitting in their local equivalent of a select() loop.

See T11350. This is a minor but reasonable UI improvement.

See PHI859. If you pass a poorly-named variable to Harbormaster, it should complain immediately.

See PHI877, which is roughly T5936: when a build is aborted, in-flight steps should be able to terminate or clean up.

See PHI919, which discusses improvements to failed/aborted messaging.

See PHI927, which requests arc:onto be a build variable.

See PHI954. When a project configures no arc linters or unit tests, it still gets an autoplan build result in the web UI. It should not. See also T13098.

See PHI929, which requests that we actually use arc.staging in describing staging ref locations. Perhaps, see also T10093.


  • See PHI932 and PHI953, which request a Herald action for preventing pushes with failed builds.

Revisions and Commits

rP Phabricator

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Add line numbers and links to the log page ... This is actually legitimately hard without scanning the entire file. Maybe we can emit a map as part of finalization which shows which has line markers every megabyte or so.

This is tricky for several reasons:

We already have similar code in Paste. It has some nice, nontrivial behaviors like dragging to select a range of lines and Quicksand/JX.History support. I can just copy/paste it, but it would be better to not just copy/paste it.

Users can link to line 1M in a 2M line log. This requires us to render a section in the middle of the log with expansion points ("Click to show more") above and below it, which isn't a state we otherwise need to render. I think the renderer (which operates on an arbitrary list of "ranges" and "views") will be able to handle this without substantial changes and I ended up needing to build the map of line markers anyway, but this may be more involved than I think.

Users can also link to lines $100000-200000, but I expect to just cap this to some maximum and treat it like $1000000-1001024, not to render 100,000 lines.

Finally, extremely long, uninterrupted lines (many megabytes of the letter "A", for example) may be split over multiple table rows. These separate rows do not have distinct line numbers: they're all "line 3" or whatever. I'm likely to just accept whatever the code does on its own here since I don't think this case is worth handling specially and suspect the default behavior will be reasonable.

Add line numbers and links to the log page with proper copy/paste behavior.

In other applications, we currently do copy/paste by rendering this:

[ 122 ] <zero width space> while (squirrel) {
[ 123 ] <zero width space>   woof();

Then we install an oncopy handler which replaces <newline>.*<zws> with <newline>.

This mostly works okay, but lacks elegance. A concrete issue is that it breaks if the text legitimately contains zero width spaces. This character is rare (I think it's purely a typesetting character, not a glyph-modifying character like "ZERO WIDTH JOINER") but may still appear in legitimate inputs.

In D19166, I Googled and then copy/pasted a different approach from StackOverflow: put the line content into the document with a CSS ::before psuedoelement. It looks like this has these advantages:

  • Will work with ZWS in the text.
  • No Javascript required / simpler implementation.
  • Generally less aesthetically offensive?

It has these known disadvantages:

  • You can't copy this text, but you can't find it with the browser's "Command-F" command either, so you can't search for a specific line number. Since linking to line numbers probably works well now (and it's rare to want to jump to a particular, arbitrary, known-in-advance line in a build log, at least) this might be a reasonable tradeoff.

Current state of the world here is:

  • Builds logs now have a link (button in the upper right) to go to the new view.
  • For logs generated after upgrading, everything in the new view should work (download, line links, arbitrarily large logs, live follow, copy/paste).
  • For logs generated before upgrading, the new view will tell you to run a command to make the log work. You can also bin/harbormaster rebuild-log --all to rebuild every log.

I'm not 100% sure that the rebuild process is final yet. In particular, I haven't tested it as much as I'd like with various extreme inputs (like very large logs with very few newlines; binary data; logs with many multibyte characters which are submitted to the logger byte-by-byte). Thus, I'm not issuing guidance to run rebuild-log --all with this release, since I think there's a good chance that you'd have to run it again after the next release if you run it now.

I expect next week will have a more-or-less final version of this, come with guidance to rebuild-log --all, and then the following week will replace the older log UI once installs have a chance to do the rebuilds.

The remaining work I expect to do is: highlighters, summarizers, testing on extreme/weird inputs, and archive/GC. I don't think any of these are too tricky but they're significant enough that they aren't going to make it in before the release cutoff.

epriestley updated the task description. (Show Details)
epriestley updated the task description. (Show Details)

See T13189#240682 for some planning on the Unit Test result table.

The unit test results also don't currently show on individual builds, which is a little whack?

Some of this touches Drydock but I'm just kicking it off the board since this mostly turned into a Harbormaster task.