Page MenuHomePhabricator

Implement a mechanism for visualising the build step order
AbandonedPublic

Authored by hach-que on Jul 3 2014, 3:20 PM.
Tags
None
Referenced Files
F14025969: D9809.diff
Thu, Nov 7, 9:35 PM
F13995490: D9809.diff
Wed, Oct 23, 1:18 PM
F13968780: D9809.id23540.diff
Wed, Oct 16, 11:00 PM
F13968778: D9809.diff
Wed, Oct 16, 11:00 PM
Unknown Object (File)
Wed, Oct 9, 4:20 PM
Unknown Object (File)
Sep 20 2024, 1:29 PM
Unknown Object (File)
Sep 19 2024, 12:10 AM
Unknown Object (File)
Sep 4 2024, 8:10 PM

Details

Reviewers
epriestley
chad
Group Reviewers
Blessed Reviewers
Summary

Depends on D9806. This implements a visualisation of the build step order using HTML canvas and Javascript. With D9806, build steps can operate in parallel, so it can be difficult to know the order it will run it without some kind of visualisation.

I'm fairly sure the Javascript in this is 99% horrible, but that could just be Javascript in general.

Test Plan

Visualised a reasonably complex build:

harbormastervisualize2.png (826×788 px, 81 KB)

Diff Detail

Repository
rP Phabricator
Branch
harbormaster-graph
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 1501
Build 1501: [Placeholder Plan] Wait for 30 Seconds

Event Timeline

hach-que retitled this revision from to Implement a mechanism for visualising the build step order.
hach-que updated this object.
hach-que edited the test plan for this revision. (Show Details)
hach-que added a reviewer: epriestley.
src/applications/harbormaster/step/HarbormasterBuildStepImplementation.php
132

Fix for previous D9806 when creating new build steps.

A more realistic visualisation:

harbormastervisualize3.png (889×785 px, 85 KB)

This shows a build with an initial start step, 3 steps that run in parallel, and then 2 steps that run sequentially at the end.

It would probably be clearer if it looked like this:

clearer.png (602×290 px, 147 KB)

Particularly, if the steps are completely linear, this will render them as:

  • A
    • B
      • C
        • D

..instead of:

  • A
  • B
  • C
  • D

...right?

This would probably be even clearer:

Screen_Shot_2014-07-03_at_10.08.17_AM.png (281×180 px, 70 KB)

..but would require we put it on a different screen. Are there use cases or reasons why it's particularly valuable to have the graph here vs elsewhere? For example, we could have some kind of like "view graph" that just pops this up, conceivably.

I'm going to rework this visualisation. I think a better solution is:

  • Simulate the build order using the build engine, but instead of performing steps assume that each step is always successful.
  • On each iteration, "finish" all of the steps that are running and start the newly available ones.
  • For each iteration, assign the steps that were started into their own row.
  • Do this without touching the DB of course.

This probably means modifying the build engine to run in a simulation mode or something like that. This has the advantages that:

  • We guarantee that the build order displayed will be identical to the way Harbormaster executes it (bar the obvious parallelisation).
  • We can render the graph like this:
    Screen_Shot_2014-07-03_at_10.08.17_AM.png (281×180 px, 70 KB)
    Because we have nodes organised into rows with their appropriate connections.

This also means we can:

  • Get rid of the ordering drag / drop interface and removing build step ordering completely.
  • Build steps are rendered out in the plan view in order of their rows (so vertically they match the build order vertically).

(Also the usage of proper names in D9806 with D9816 makes this a lot less urgent)

This probably needs some significant rework, so I'm going to abandon this for now (to get it out of my queue).