Builds Page
The Builds page shows information about the builds executed using IncrediBuild (In this document and in the dashboard terminology, a build refers to any execution that was executed with IncrediBuild and not only compilations). This includes both general information about build execution across your entire deployment as well as specific information about specific builds and executing Agents (i.e. Initiators). You can set filters to specify the parameters for the data represented and displayed on this page.
On this page:
Filters
Filters allow you to set the parameters for the data that is represented on the Builds page.
Note: All measures displayed on this page represent only to the data within the parameters set from the build Filters.
Page Header
In the Page Header, below "Builds Overview", the Valid For information is displayed. This shows the date and time that the data represented on this page was last refreshed. This is considered to be the current time regarding the time filters set for the page. The data refreshes automatically every hour, assuming that the Time Filter is set for a time range that is dependent on the current time.
Note: You can update the current time manually by refreshing the page. However, refreshing the page will also reset any filters that you have set and return them to their default settings.
Time Filter
The Time filter enables you to filter the data represented on the Builds page to include only builds run during the specified time period.
You can set the time filter using one of the preset time range buttons or you can create a custom time range.
The preset time ranges are described in the following table:
Note: In the descriptions below, the Current time refers to the time that the data on the page was last refreshed.
Category | Description |
|---|---|
12H | Includes data from builds executed in the 12 hours prior to the current time. |
24H | Includes data from builds executed in the 24 hours prior to the current time. This is the default selection. |
Today | Includes data from builds executed from 00:00 of the current day up to the current time. |
To set a custom time range:
- Click on Custom in the Page Header filter pane.
2. Pick a Date Range window is displayed:
3. Click on the From Date field.
- A calendar selection window is displayed.
- Select a date.
- The default is set for the current date.
- To select a date from a previous month, click the back arrow on the top of the calendar and then select a date.
- Click OK.
4. Do the same for the end date.
Product Filter
The Product filter enables you to filter the data represented on this page to include only builds associated with a specific product (or products). The product profiles must first be created in the Products Configuration page before they can be applied to the Builds page .
.
To set the Product filter:
Click on the Product field.
A multi-select list of products is displayed:
Click the checkbox next to each of the products to be included.
Notes:
- Once this filter is applied, the filter will be marked.
- The default value is set to include all build commands regardless of products.
- If no products have been created an option to Add Products is displayed in the Product filter drop down menu.
Build Types Filter
The Build Types filter enables you to filter the data represented on the Builds page to include only builds of a specified type. You can select one or more Build Types to be included in the data displayed.
Note:
- Specific Build Types are registered for Visual Studio builds which are executed through the IDE or the IncrediBuild BuildConsole command line. All other builds or other executions are registered as Unknown.
The Build Types are described in the following table:
Category | Description |
|---|---|
Build | An Incremental build operation of a Visual Studio solution or project/s. |
Clean | A clean build operation of a Visual Studio solution or project/s. |
Rebuild | A full rebuild operation, which consists of Clean and Build operations of a Visual Studio solution or project/s. |
Unknown | Other IncrediBuild executions which are not Visual Studio compilations. |
To set the Build Types filter:
- Click on the Build Types field from the Page Header filters pane.
- A multi-select list of the Build Types is displayed.
- Click the checkbox next to each of the Build Types to be included.
- The filter is applied. The selected Build Types are shown on the display.
Note: The default is set to display all Build Types.
Builds KPI Summary
The Builds KPI Summary shows aggregated statistics for the KPI measures related to build usage of the IncrediBuild Infrastructure.
Notes:
- All data represented on the Builds page, including the KPI Summary are based on the parameters set in the Builds filters.
- That means that data for a build is only represented in the measures on this page if the build was run during the selected time period, was related to the selected Product type, was of the selected build type and was initiated by the selected Initiator Group.
The information displayed in the KPI Display is explained in the following table:
Category | Description |
|---|---|
Builds Executed | The total number of builds executed using IncrediBuild. |
Build Status | Successful - The number of builds successfully completed by IncrediBuild. |
Avg. Build Duration | The average time that it took to execute each build using IncrediBuild. |
Distributed [%] | The percentage of the total time were executed remotelybuilds execution that was done on remote as opposed to local Agents. This value is calculated by taking the total duration of builds all executed on remote Agents cores and dividing it by the total duration of builds executed on all Agents remote and local cores.(including local Agents). For example: if a build was executed on the local Agent as well as 9 remote Agents cores and the execution of each task lasted for one hour, then we divide the 9 hours of execution on remote Agents cores by the total of 10 hours of execution which would yield the result of 90% build tasks distribution.The percentage of the tasks executed with IncrediBuild that were executed on remote Agents. This value is calculated by taking the number of core-hours of execution on remote cores and dividing it by the total number of core-hours of execution on all cores (including the local cores). For example, if a build was executed on the local Agent, which has one core, as well as on 9 remote cores and the execution took one hour, then we divide the 9 core-hours of execution on remote cores by the total of 10 core-hours of execution which yields the result of 90% Distributed execution.This is not accurate. This value is the sum of the duration of all tasks executed remotely divided by the sum of all the tasks executed both remotely and locally. Talk to me if this is not clear. For example, if a build consists of 16 tasks each taking 1 minute, 4 of them were executed locally and 12 were executed remotely, the value will be 12/16=75% All of the revisions are making this definition too complex. I started from scratch and wrote a straight forward definition, using the concept of core-hours that I introduced above. |
Builds Execution Over Time Graphic Display
This area shows a graphic representation of the Builds KPIs over time. In the top graph you can select to display either Successful vs. Failed builds over time or Build Types over time (Default: displays Success vs. Fail graph). The lower graph shows the Distributed percentage over time (for an explanation of this measure see Builds KPI Summary). The data displayed for a given point in time relates to all builds which began execution during the time period between the last aggregation of data and the specified time.
- The data shown in the graph is aggregated hourly for the last two weeks and daily for earlier dates.
- The legend indicating the color of the display for each element is shown at the top of the graph.
You can interact with the display in the following manner:
- Select/Deselect – Click on one of the data elements in the legend to show/hide that element in the display. The default is to display all elements. Therefore, the first time that you click on an element it will hide it.
Note: If a Build Type has been excluded by a filter then data for that Build Type will not be displayed even if it has been selected in the legend.
- Display data – Hover over a point in the graph to create a pop-out display of the specified date and time and the data for that particular point in time.
Note: The graphs are linked so that hovering over a point in one graph creates a pop-out display of data also in the second graph.
- Zooming – Drag the cursor over a section of the timeline to zoom in on that time range and display a more granular breakdown of the data over a shorter period of time. To return to the display of the full timeline, click the Reset Zoom button in the top right corner of the graph.
This section shows two bar charts representing either the top or bottom Agents for each of the two measures Time Spent Building and # Builds Executed. You can select the parameters for the data displayed in these charts using the Build Filters. Underneath the title of each chart there is a legend indicating the color of the display for each Agent.
Agent Number Filter
You can select the number of Agents displayed from the dropdown list for the Agent Number Filter (options are: 5,10 or 20) from the filter pane. You can also select whether to display the Agents with the top performance or the Agents with the bottom (lowest) performance.
Time Spent Building
This measure shows the aggregate of the duration of all builds initiated by a particular Agent. Either the top or bottom Agents are illustrated on the display based on your selection.
The legend shows the names of the Agents and the number of hours.
You can interact with the display in the following manner:
- Select/Deselect – Click on one of the Agent names in the legend to show/hide that Agent for display. The default is to display all Agents. Therefore, the first time that you click on an Agent it will hide it.
- Display data – Hover over the bar of an Agent to create a pop-out display. The display includes: the name of the Agent, the percentage of time spent building in relation to the total time that the Agent was connected to the Coordinator and the total duration of time spent building.
Number of Builds Executed
This measure shows the total number of builds initiated by a particular initiator Agent (both successful and failed builds are included in this measure). Either the top or bottom Agents are displayed depending on your selection The legend shows the names of the Agents and the number of builds.
Note: This chart relates only to the number of builds and not to their duration. Therefore, the list of Agents shown and the order in which they appear will not necessarily be the same as in the Time Spent Building chart.
You can interact with the display in the following manner:
- Select/Deselect – Click on Fail or Success in the legend to show/hide that element for display. The default is to display both successful and failed builds.
- Display data – Hover over the bar of an Agent to create a pop-out display of the name of the Agent together with the total number of builds, the number of successful builds and the number of failed builds.
5 Longest Builds Display
This pane shows the 5 individual build executions that had the longest durations. Clicking on one of the builds displays a window with detailed information about that particular build. 
The parameters displayed in this window are described in the following table:
Item | Description |
|---|---|
Agent Name | The name of the initiator Agent. |
Status | The status of a build is either Success or Failed. |
Duration | The time that it took to execute the build. |
Distributed [%] | The percentage of the build that was executed using remote Agents (i.e. Helpers) as opposed to the local Agent (i,e, Initiator). This value is calculated by taking the total duration of the build executed on remote Agents and dividing it by the total duration of builds executed on all Agents (including the local Agent). For example: if a build was executed on the local Agent as well as 9 remote Agents and the execution lasted for one hour, then we divide the 9 hours of execution on remote Agents by the total of 10 hours of execution which would yield the result of 90% build distribution.The explanation is not accurate in the same manner as above The percentage of the tasks executed with IncrediBuild that were executed on remote Agents. This value is calculated by taking the number of core-hours of execution on remote cores and dividing it by the total number of core-hours of execution on all cores (including the local cores). For example, if a build was executed on the local Agent, which has one core, as well as on 9 remote cores and the execution took one hour, then we divide the 9 core-hours of execution on remote cores by the total of 10 core-hours of execution which yields the result of 90% Distributed execution. |
Avg. Additional Cores Needed | This value indicates the average number of additional cores (beyond the number of cores that were available) that could have been used to execute the build. During a build's execution, the system registers a value every second for the number of additional cores needed. Therefore, this value is determined by taking the aggregate of the number of cores needed for each second and dividing the sum by the number of seconds that the build was executed. For example, a value of '0' indicates that adding more cores to the deployment would not improve the efficiency of the build. A higher value indicates that adding additional cores could potentially increase the performance of the build. |
Peak Additional Cores Needed | The highest value registered for additional cores needed at any point during the build. |
Time Saved | This is a rough estimate of how much longer it would have taken to run this build if it was executed entirely on the initiator Agent. The calculation is made by taking the aggregate of the core-hours (a core-hour is an hour of utilization of each core, i.e. a 4 core machine running for one hour would be considered to have utilized four core-hours) of utilization of all remote (i.e. helper) Agents and dividing that by the number of cores on the local Agent. Since usage of the remote Agents is less efficient than usage of the initiator Agent (because of I/O and Network factors etc.), the result is divided in halfby 1.5. For example, if the initiator Agent has 4 cores and the build ran for an hour using an additional 12 cores on remote Agents. Then we take the 12 core-hours and divide that by the 4 cores on the initiator Agent which yields the result of 3 hours. We then take that number and divide it in halfby 1.5 to reach the result that the Time Saved was 1.52 hours. |
Avoid Local | This is a Boolean field that was set by the user who initiated the build. |
Start Time | The date and time that the build execution began. |
End Time | The date and time that the build execution was completed. |
Avg Used Cores | The average number of cores used at a given point in time during the build execution. The number of cores being used is registered for every second. Therefore, this value is determined by taking the aggregate of the number of cores being used for each second and dividing the sum by the number of seconds that the build was executed. |
Product | If a specific product or products are associated with the build command, then the product name/s are displayed. |
Command | The complete command line that was used to execute the build. |
5 Top Distributed Builds Display
This pane shows the 5 individual build executions that achieved the highest Distributed Build percentage (for an explanation of this measure see Builds KPI Summary). Clicking on one of the builds displays a window with detailed information about that particular build. The data elements displayed in this window are the same as those displayed for the 5 Longest Builds (for an explanation of the elements see 5 Longest Builds Display).
Builds Grid
This pane displays detailed information about specific builds. A list of up to 10 builds is displayed at a time with a series of columns displaying detailed data about each build. You can scroll through the rest of the list by clicking the forward and backward arrows below the grid. You can customize the display by selecting which data columns are displayed. The builds can be sorted in ascending or descending order in relation to each of the columns. The data can be accessed in a manner that enables more in-depth analyses by entering Analysis Mode.
Builds Grid Filter
From the Build Grid Filter you can select which columns are displayed (for an explanation of the data displayed in each column see the Column Definition Table below). You can also enter Analysis Mode to enable more in-depth data analyses.
To select which columns are displayed:
- Click Columns.
- A multi-select dropdown list of column categories is displayed.
- Select the check-box next to each of the columns to be displayed.
- If a column is selected, you can click the check-box to deselect the column. (Default: the top 6 columns in the list are selected).
- The selected columns are displayed in the grid.
Notes:
- Specific Build Types are registered for Visual Studio builds which are executed through the IDE or the IncrediBuild BuildConsole command line. All other builds are registered as Unknown.
If there is not sufficient space on the screen to display all of the selected columns then a horizontal scrollbar appears below the grid to scroll across to the additional columns.
To enter Analysis Mode:
- Click Analysis Mode under the Builds Grid Filters choices.
Sorting
You can sort the builds listed in the grid in ascending or descending order for each of the columns.
To sort the builds listed in the grid:
- Click the up-arrow next to a column title to sort according to the values for that column in descending order (i.e. from highest to lowest).
- Or, click the down-arrow next to a column to sort according to the values for that column in ascending order (i.e. from lowest to highest).
Note: Sorting the grid according to a particular column changes the order in which the builds are listed, which impacts on the display of the entire grid not just the selected column.
Column Definition Table
Item | Description |
|---|---|
Build Caption | This is a string expression that represents a specific build execution. This can be user-defined or automatically generated. It may incorporate the name of the solution for which the build was executed. If the build was executed through the command line and the Title command argument wasn't specified then no Build Caption is applied and this field remains empty. |
Status | The status of a build is either Success or Failed. |
Start Time | The time at which the build began execution. |
Duration | The duration of time that it took to execute the build. |
Initiator | The name of the initiator Agent. |
Distributed | The percentage of the build that was executed using remote Agents (i.e. Helpers) as opposed to the local Agent (i.e. Initiator). This value is calculated by taking the total duration of the build executed on remote Agents and dividing it by the total duration of builds executed on all Agents (including the local Agent). For example: if a build was executed on the local Agent as well as 9 remote Agents and the execution lasted for one hour, then we divide the 9 hours of execution on remote Agents by the total of 10 hours of execution which would yield the result of 90% build distribution.Same comment as above The percentage of the tasks executed with IncrediBuild that were executed on remote Agents. This value is calculated by taking the number of core-hours of execution on remote cores and dividing it by the total number of core-hours of execution on all cores (including the local cores). For example, if a build was executed on the local Agent, which has one core, as well as on 9 remote cores and the execution took one hour, then we divide the 9 core-hours of execution on remote cores by the total of 10 core-hours of execution which yields the result of 90% Distributed execution. |
Avg. Cores Used | The average number of cores used at a given point in time during the build execution. The number of cores being used is registered for every second. Therefore, this value is determined by taking the aggregate of the number of cores being used for each second and dividing the sum by the number of seconds that the build was executed. |
Build Command | This is the command line with which the build was executed. Because it is a long string it is not displayed in the grid. The word 'show' is displayed for all entries in this column. Hovering over 'show' for a specific build generates a pop-out window with the full Build Command string. |
Build Type | The type of build that was executed. The following are the possible Build types:
|
Estimated Time Saved | This is a rough estimate of how much longer it would have taken to run this build if it was executed entirely on the initiator Agent . The calculation is made by taking the aggregate of the core-hours (a core-hour is an hour of utilization of each core, i.e. a 4 core machine running for one hour would be considered to have utilized four core-hours) of utilization of all remote (i.e. helper) Agents and dividing that by the number of cores on the local Agent. Since usage of the remote Agents is less efficient than usage of the initiator Agent (because of I/O and Network factors etc.), the result is divided in halfby 1.5. For example, if the initiator Agent has 4 cores and the build ran for an hour using an additional 12 cores on remote Agents. Then we take the 12 core-hours and divide that by the 4 cores on the initiator Agent which yields the result of 3 hours. We then take that number and divide it by 1.5in half to reach the result that the Time Saved was 1.52 hours. |
End Time | The time that the build was completed. |
Avg. Additional Cores Needed | This value indicates the average number of additional cores (beyond the number of cores that are currently available) that could have been used to execute the build. The system registers a value every second for the number of additional cores needed, so that this value is determined by taking the aggregate of the number of cores needed for each second and dividing the sum by the number of seconds that the build was executed. For example, a value of '0' indicates that adding more cores to the deployment would not improve the efficiency of the build. A higher value indicates that adding additional cores could potentially increase the efficiency of the build. |
Peak Cores Needed | The highest value registered for additional cores needed at any point during the build. |
Peak Cores Used | The highest number of cores that were used simultaneously at any point during the build. |
Avoid Local | This is a Boolean field that was set by the user who initiated the build. |
Product | If a specific product or products areOr products associated with the build command, then the product name/s is displayed. |