1. Key Features
2. Starting Build Central
3. Main Grid View
   • Build From Selection
   • Number Columns (Commit Number/Date/Username/Commit Title)
   • Extension Columns
   • Build Info
   • Views
4. ‘Set Versions’-tab
   • Steps for Setting Versions on Extensions
5. ‘Build’-tab
   • Steps for Building Extensions
   • Options and Buttons
6. ‘Upload’-tab
   • Steps for Uploading Extensions
7. 'Continuous Builder'-tab
   • Steps for Starting Continuous Builder
   • Workflow for Starting Autotest
   • ‘Settings’-button

Build Central is one of the many tools of CET Developer (The collection of tools).

Key Features

• Filter the view from different extensions
• Chang version numbers of extensions
• Build extensions
• Upload built extensions for publishing
• Monitoring your codebase (automatically checking and building your extensions as soon as new code is submitted and send an e-mail to anyone submitting code with compile errors)

Starting Build Central

To start Build Central, select a workspace in Operator and click Build.

Main Grid View

In the grid view, you see all extensions included in your workspace. The extensions are grouped as Core, Abstract and then one group for your customization (or multiple if you have more than one). The groups can be expanded/collapsed by clicking the column headers.

Build From Selection

In the left of the window, you will see two selections and a filter for extensions

The Build From selections are indicated where build central build from: 

• Build From Local File
  The default build method. Uses code locally on your computer to create the extension. Commonly used to create test builds from what you've changed locally.
• Build From Commits
  Fetches and lists down from the server all the commits in the branch you're currently in, and you can selectively build from one of the commits.

The Filter is helping to split extensions into few types:

• Status
• Type
• Group

Number Columns (Commit Number/Date/Username/Commit Title)

The first column in the grid view is Number column that show commit number, date, username and commit title of each commit/row. When using Build Central in Build From Local Files, it indicates the local code in the workspace is used and it may not correspond to any specific commit. 

Extension Columns

Each extension group and extension has its own column where it shows:

• Extension version number
• Build status
• Build time

For an extension group, the version may be prefixed with a ‘~’, indicating that not all extensions in the group have the same version number (the highest version number in the group will be shown). So if all extension in the group except for one has the version number “6.0.0.5”, the version for the group will be displayed as “~6.0.0.5”.

Build status and build time are shown for both 32- and 64-bit versions of the extensions.

Build status can be one of the following:

• Success (extension was built successfully without warnings)
• Warning (extension was built with warnings)
• Error (extension contains error(s) and was not built)
• In progress (extension build in progress)
• Unknown (extension has not been built yet)

Build time is the time it took to build the extension/group. It can be useful for comparing build time on different machines and between different versions.

Build Info

By right-clicking an extension or extension group that has been built, and click Show Log File, you can see information from the build log file in the CET Developer Studio - Log Viewer.It shows info for the currently selected extension(s)/group(s).

Views

You can create views that only the extensions you select. You do this by:

1. Click Add new (to the right of the view tabs) and type in a name of the view
2. You can now right-click on columns, or a cell selection and select Hide Column(s) from View in order to hide them from this view.
3. If you want to restore hidden columns in a view, you can right-click the tab/view name and select the hidden columns in the Add Column to this View-submenu.

‘Set Versions’-tab

This tab is used for setting versions of your extensions. You can set versions for selected extensions in the grid view, and the versions are then set in the extension files (extension.xml) and package files (package.cm) of the extensions. A commit that contains the changed files is created and can then be submitted manually (changed files are never submitted automatically – you always have the chance to review the changes before submitting them).

Steps for Setting Versions on Extensions

1. Select the extension(s) you want to set the version for (this can be both extension groups or extensions within groups).
2. Click the Edit Version button. You will now see a new row on top of the grid with version numbers filled in for the extension(s) you selected. It will by default take the highest selected version and increase its revision number (third number) by 1 (setting build, 4th number to 0). So if the highest selected version is “6.0.0.2”, it will suggest “6.0.1.0” as the new version. If you want to manually specify a new version number you can do this by selecting the Set To option at the top and fill in any number you want.
3. Click Create Commit button when the new row in the grid contains the version numbers you want to set: This will write the new version numbers to the files and create a commit with all the modified files checked out.
4. Open Git where you can see and submit the newly created commit.

‘Build’-tab

In this tab, you can build selected extensions.

Steps for Building Extensions

1. Select the extension(s) you want to set the version for (this can be both extension groups or extensions within groups).
2. Review the build settings (Beta or Release, 64-bit).
3. Click Build (Beta/Release) button.

Options and Buttons

• ‘Beta’/’Release’-option
  The beta/release flag will set a property within the extension which can be accessible from its code (can for example be used to alter toolbox images to indicate that it’s a beta-version if the extension). Also when building beta-version of an extension, the text [beta] will be suffixed to the name and filename of the extension.
  
  
• ‘Output Folder’-button
  This button opens an explorer window to the folder where built extensions are put.
  
  
• "Send e-mail when build is finished"-button
  This button will trigger the build email service, when the build is done it will send an email to the MailRecipitents.(you maybe need to fill out email addresses in Settings)
  
  
• "Show Performance Tests"-button
  This button will show the performance tests in extension columns.

‘Upload’-tab

From this tab, you can upload your built extension to MyConfigura for publishing.

Steps for Uploading Extensions

1. Select the extension(s) you want to upload (this can be both extension groups or extensions within groups).
   The Name for upload batch text field will by default be filled in based on the highest version of selected extensions, and "Local"/commit number. The name is used to identify the upload batch on MyConfigura and you can change it if you want.
2. Click Upload
   Wait until all files have been uploaded.
3. Click the Developer Center button to see and publish your uploaded extensions on MyConfigura.

'Continuous Builder'-tab

The Continuous builder is used to automatically build extensions when new changelists are submitted. If anyone submits code that introduces compile errors, you can have the builder send an e-mail to that developer (and to additional e-mail addresses as well). It can also save the latest builds, so you can for example pick built extensions recently built for upload to MyConfigura for beta testing. You can upload previously built extensions while the builder is running without having to interrupt it.

‘Settings’-button

There are a few settings that are used by the continuous builder.

• SendMailToUserOnTestActionErrors
  If true, an e-mail will be sent to the user when the test action fails in the build.
  
  
• SendMailOnEveryError
  If true, an e-mail will be sent to the user whenever there is an error happening in the build.
  
  
• SendMailToUserCausingError
  If true, an e-mail will be sent to the user who has submitted a commit if it breaks or fixes the build.
  
  
• MailRecipients
  E-mail addresses that are to receive a notification every time a build breaks or is fixed. These recipients will always get e-mail notifications when the build is broken/fixed regardless of the setting “SendMailToUserCausingError”.