Add reusable build information card

[williamjallen]

Most build-specific pages currently display a basic table of information about that build. For example:

This primitive approach uses a significant amount of vertical space, while wasting most of the horizontal space available at the top of the page. Additionally, this table does not display site information or build history information, which means that it is often augmented by UI elements which take up additional vertical space.

This PR introduces a new reusable "build information card" Vue component which accepts a build ID and displays a large amount of summary information about a build and associated site in a collapsible format.

Example of the card in its closed form:

Example of the same card in its open form:

This PR implements the basic functionality, but there are a few future improvements to be made, including:

• The horizontal space to the right of the build summary card is reserved for charts showing the history of the build.
• The horizontal space to the right of the site information card is reserved for charts showing the time allocation of the site, including the amount of time spent on the associated project. A map showing the location of the site (if site locations are enabled) is another future improvement to be made.

I have added this component to the list of components to be tested via Cypress component testing once type-safe GraphQL mocking is ready for use.

[bartlettroscoe]

@williamjallen, a few comments/suggestions/questions:

Comment: Thinking how to compactly show this information is good since it will impact almost every CDash page 😊

Suggestion: Can we make it so that the "build information card" in the closed/compact form contains at least the key info to unambiguate that build from every other build: "site", "buildname", "buildstarttime", and "group" (and "subproject" if this is for only a single subproject)? All of that info should easily fit on one or two lines in this card. We need that basic info to be able to differentiate this build from other builds in an unambiguous way. Anything extra is gravy. With the current example:

it seems obvious that some of the basic info is:

• "site" = "Dash20.kitware"
• "buildname" = "Win32-MSVC2009"
• "group" = "Nightly"

?

But that does not show "buildstarttime". Perhaps the relative time "15 years ago (2 min, 29 sec)" is for the buildstarttime, but is not very direct and fails when you take a screenshot. Instead, the format should be "YYYY-MM-DD HH:MM:SS TZ" to make the buildstarttime unambiguous. If you want to provide a tool-tip to provide the relative time, then that is fine as well. (The relative buildstarttime could also be shown in the expanded card as well.)

Also, could we provide tool-tips to define each of these pieces of info in the card to remove any ambiguity? For example, I was not sure at first what "Dash20.kitware" represented. In the above example, hovering the mouse over "Dash20.kitware" would show "site", hovering over "Win32-MSVC2009" would show "Build name", and hovering over "Nightly" would show "Group".? Likewise for "Build start time" (once that field is added).

Question: In the example:

what does the following info represent:

• "Windows XP Professional"
• "ctest2.6-patch"
• "0"

?

I am guessing that "Windows XP Professional" is for the operating system and "ctest2.6-patch" is for the version of CMake/CTest being used? Does the latter give the exact Git tag and "0" is the number of commits after that tag? Otherwise, this info "ctest2.6-patch" is ambiguous and therefore not very useful. I am not sure the CMake version is worth showing on the closed card. (Perhaps this could be generalized for the "version" for the software project, as configured. For example, it could be produced from git describe or could be the SHA1, or both?)

Question: What will be the cost of additional history info in the expanded card when loading these pages? I think it needs to be very very cheap. Otherwise, just provide a link to a page that will summarize that info (like the builds/<buildid> page). If this will cost something, can we make it so that the history info does not get queried or loaded until after the "build information card" is expanded?

Comment: Otherwise, I am curious to get other people's opinions on what this info should like like.

[williamjallen]

Suggestion: Can we make it so that the "build information card" in the closed/compact form contains at least the key info to unambiguate that build from every other build: "site", "buildname", "buildstarttime", and "group" (and "subproject" if this is for only a single subproject)? All of that info should easily fit on one or two lines in this card. We need that basic info to be able to differentiate this build from other builds in an unambiguous way.

As noted at the bottom of the PR description, the build group and subproject information isn't exposed via GraphQL yet, so that will be added in a separate PR.

it seems obvious that some of the basic info is:

• "site" = "Dash20.kitware"
• "buildname" = "Win32-MSVC2009"
• "group" = "Nightly"

Correct, except that the "Nightly" is actually the type of build.

But that does not show "buildstarttime". Perhaps the relative time "15 years ago (2 min, 29 sec)" is for the buildstarttime, but is not very direct and fails when you take a screenshot. Instead, the format should be "YYYY-MM-DD HH:MM:SS TZ" to make the buildstarttime unambiguous. If you want to provide a tool-tip to provide the relative time, then that is fine as well. (The relative buildstarttime could also be shown in the expanded card as well.)

Yes, the relative time is the build start time. My thought is that a relative timestamp is easier to read quickly, and that users can open the card if they want to see the exact timestamp. Taking a screenshot of only the closed card seems unlikely to me--wouldn't most people open it if they were interested enough to take a screenshot? While I'm in favor of leaving a relative timestamp personally, I could be convinced otherwise.

Also, could we provide tool-tips to define each of these pieces of info in the card to remove any ambiguity? For example, I was not sure at first what "Dash20.kitware" represented. In the above example, hovering the mouse over "Dash20.kitware" would show "site", hovering over "Win32-MSVC2009" would show "Build name", and hovering over "Nightly" would show "Group".? Likewise for "Build start time" (once that field is added).

Sure, I'll add tooltips for each of the elements.

Question: In the example:

what does the following info represent:

• "Windows XP Professional"
• "ctest2.6-patch"
• "0"

?

I am guessing that "Windows XP Professional" is for the operating system and "ctest2.6-patch" is for the version of CMake/CTest being used? Does the latter give the exact Git tag and "0" is the number of commits after that tag? Otherwise, this info "ctest2.6-patch" is ambiguous and therefore not very useful. I am not sure the CMake version is worth showing on the closed card. (Perhaps this could be generalized for the "version" for the software project, as configured. For example, it could be produced from git describe or could be the SHA1, or both?)

• The "Windows XP Professional" here is the combination of various pieces of operating system information which were preciously presented as separate rows in the build information table.
• The "ctest2.6-patch" here is the generator for this build, if that info was submitted. The actual meaning of the string itself is a CTest issue, and is not manipulated or constructed by CDash in any way. I put the information there since it was pretty much the only thing not listed elsewhere, but perhaps it isn't relevant in most cases and should be removed.
• Not shown in this screenshot (since the example build I selected predates its availability) is compiler information. If compiler information is submitted, it shows up next to the generator.

Question: What will be the cost of additional history info in the expanded card when loading these pages? I think it needs to be very very cheap. Otherwise, just provide a link to a page that will summarize that info (like the builds/<buildid> page). If this will cost something, can we make it so that the history info does not get queried or loaded until after the "build information card" is expanded?

The information is loaded asynchronously, so the load time of this card does not meaningfully affect the load time of the rest of the page. The build history charts planned for the open space on the right will also load asynchronously. Having components load only the exact data they need asynchronously is one of the main benefits of using a GraphQL API with Vue. The goal is to roll this out to the entire site eventually, which should vastly improve the perceived slowness of many pages.

[bartlettroscoe]

As noted at the bottom of the PR description, the build group and subproject information isn't exposed via GraphQL yet, so that will be added in a separate PR.

👍

Correct, except that the "Nightly" is actually the type of build.

Which is why a tool tip might be useful?

Yes, the relative time is the build start time. My thought is that a relative timestamp is easier to read quickly, and that users can open the card if they want to see the exact timestamp. Taking a screenshot of only the closed card seems unlikely to me--wouldn't most people open it if they were interested enough to take a screenshot? While I'm in favor of leaving a relative timestamp personally, I could be convinced otherwise.

Would the relative time be shown only for the last 24 hours? Would this switch to absolute date/time after 24 hours, like you see on other pages like the index.php page?

Sure, I'll add tooltips for each of the elements.

👍

• The "ctest2.6-patch" here is the generator for this build, if that info was submitted. The actual meaning of the string itself is a CTest issue, and is not manipulated or constructed by CDash in any way. I put the information there since it was pretty much the only thing not listed elsewhere, but perhaps it isn't relevant in most cases and should be removed.

Just curious where that comes from and if the project might be able to specialize that field from some bit of data that CTest sends up to CDash.

The information is loaded asynchronously, so the load time of this card does not meaningfully affect the load time of the rest of the page. The build history charts planned for the open space on the right will also load asynchronously. Having components load only the exact data they need asynchronously is one of the main benefits of using a GraphQL API with Vue. The goal is to roll this out to the entire site eventually, which should vastly improve the perceived slowness of many pages.

So the page elements will fill in as the queries and formatting for each element are completed? What does that look like before the elements are filled in? Just curious.

[williamjallen]

Yes, the relative time is the build start time. My thought is that a relative timestamp is easier to read quickly, and that users can open the card if they want to see the exact timestamp. Taking a screenshot of only the closed card seems unlikely to me--wouldn't most people open it if they were interested enough to take a screenshot? While I'm in favor of leaving a relative timestamp personally, I could be convinced otherwise.

Would the relative time be shown only for the last 24 hours? Would this switch to absolute date/time after 24 hours, like you see on other pages like the index.php page?

That's another interesting idea to consider. Perhaps a good model for this is the way GitHub formats timestamps. Timestamps are relative for the first week, and then switch to a short date string. That would provide enough information to be useful, while also minimizing clutter. Users would still be able to open the card (or hover over the date) to get the entire date string.

• The "ctest2.6-patch" here is the generator for this build, if that info was submitted. The actual meaning of the string itself is a CTest issue, and is not manipulated or constructed by CDash in any way. I put the information there since it was pretty much the only thing not listed elsewhere, but perhaps it isn't relevant in most cases and should be removed.

Just curious where that comes from and if the project might be able to specialize that field from some bit of data that CTest sends up to CDash.

@zackgalbreath is probably the most knowledgeable about the exact details of how the generator string is created.

The information is loaded asynchronously, so the load time of this card does not meaningfully affect the load time of the rest of the page. The build history charts planned for the open space on the right will also load asynchronously. Having components load only the exact data they need asynchronously is one of the main benefits of using a GraphQL API with Vue. The goal is to roll this out to the entire site eventually, which should vastly improve the perceived slowness of many pages.

So the page elements will fill in as the queries and formatting for each element are completed? What does that look like before the elements are filled in? Just curious.

If the content takes a nontrivial amount of time to load, a loading indicator will be displayed until the content is available. The content isn't displayed (or even inserted into the DOM) until the data is ready to be rendered. In reality, the period of time where the data is not available is imperceptible. As an arbitrary example of the same concept, you can see the beta tests page for this recent CMake build (or any other build).

[bartlettroscoe]

@williamjallen, just note that build names can get very long. For example, Trilinos has build names as long or longer than:

• PR-13416-test-rhel8_sems-cuda-11.4.2-gnu-10.1.0-openmpi-4.1.6_release_static_Volta70_no-asan_complex_no-fpic_mpi_pt_no-rdc_no-uvm_deprecated-on_no-package-enables-493

So it is quite possible that just the build name will take up the entire first line and will need to word-wrap. So how would that work with a compressed window and the build group (or the build model in the above example) on the same line? Would that look like:

Could you please test this with absurdly long names for "site", "buildnamed", "group", and "subproject" and make sure this is formatted in a reasonable way?

FYI: Note that the current table-based summary at the top is not doing a great job with long names either as it does not resize the table or wordwrap. For example, here you see the full table as:

but when you shrink the window horizontally, it cuts off the long build name:

Let's please make sure and have CDash better handle long names for everything and correctly word-wraps these. (Related to this, there is at least on project at SNL that has test names that can be 400 chars long!)

[williamjallen]

@bartlettroscoe Yes, graceful word wrapping was a major part of designing this UI. When the card is closed, the text is truncated to prevent the card from becoming too large. When the card is opened, the text wraps to display the entire build name. The same concept applies to the other text as well. Here's an example with the build name you provided:

Closed:

Open: