Managing build processes

Build processes define the input, transformational processes, and expected output of projects

Before you create a build process, complete these actions:

Create a process. See Creating process definitions.
Create at least one job and add it to the process. See Creating jobs.

Build process input is source code that is stored in an SCM. The actions that transform source code into the expected output are defined by processes and jobs. The results are called build artifacts.

From the IBM® UrbanCode™ Build dashboard, click Projects, and then select a project.
Click Configuration.
On the Configuration page, click New in the Build Processes area.
Define the process by completing these steps:
1. Select a process template from the Template list.
  For information about build process templates, see Creating build process templates.
2. Type a name for the process in the Name field.
3. Select a team to manage the process from the Team list.
4. Select a scheme from the Notification Scheme list.
  For information about notification schemes, see User notifications.
  Note: If a notification scheme is not selected for the process, notification subscriptions will not work. For information about managing notification subscriptions, see Managing notification subscriptions.
5. Select a priority option from the Priority list.
  Priority options determine when processes run. Processes with a High priority run before processes with Normal or Low priorities. Processes with Normal priority run before processes with Low priority. When a process begins, it is not suspended or stopped when a higher-priority process is requested. Normal is the default option.
6. Select an option from the Skip Pre-Processing options.
  If you select Yes, build preprocessing, such as checking for source changes, is skipped. The default selection is No. For information about preprocessing, see User notifications.
7. Click Save.
Define a source configuration by completing these steps:
1. Click Create in the Source Configuration area.
2. Using New Source from Template window, select a template from the Source Template list.
  For information about creating source templates, see Creating source templates.
3. Type a name for the source configuration in the Name field.
4. Select a repository from the Repository list.
Optional: Add process properties by completing these steps:
1. Click Create in the Properties area.
2. Type a name for the property in the Name field.
3. Specify whether users can override the default value by selecting the User May Override option.
  If selected, users are prompted to specify a value when they run the process.
4. Enter a value for the property in the Value field.
Optional: Define a build configuration by completing these steps:
1. Click Create in the Build Configurations area.
2. Type a name for the build configuration in the Name field.
3. Optional: Specify values for the available properties.
  The properties are derived from the project templates and vary depending on the project.
4. Click Save.
Define dependencies for the build process by completing these steps:
1. Click Dependencies.
2. Select an option from the Conflict Strategy list.
  This option determines what happens when a dependency conflict occurs. Fail means do not continue until conflicts are resolved. Favor Old means that the oldest build's artifacts are used. Favor New means that the newest build's artifacts are used. Fail is the default option.
3. Select Trigger Only Dependencies if you want dependencies to trigger only builds.
  If cleared, dependencies trigger builds and set additional dependencies. Select this option when dependencies are determined by external dependency management tools, but you want to use dependencies as triggers. The default option is cleared.

Define a trigger by completing these steps:

Click Triggers, and then click New Trigger.

Select a trigger type from the Type list, and click Select.

The trigger types are described in the following table.

Table 1. Trigger types
Trigger type	Description
Scheduled Trigger	Scheduled triggers run on their own timers that poll the SCM tools for changes. When changes are detected, the build starts at the scheduled time. Scheduled triggers can be configured to force builds regardless of whether source changes occurred.
Repository Trigger	Repository triggers initiate builds whenever source code changes occur in the repository.
Post-Process Trigger	Post-processing triggers listen for post-processing events. When an event is detected, it can trigger other events. See Creating post-processing scripts.

Type a name for the trigger in the Name list.
Optional: If you selected Scheduled Trigger, select a schedule from the Schedule list.
For information about schedules, see Creating schedules.
Select Force to force builds when triggers occur.
If Force is selected, builds are triggered even if source changes are not detected.
Select a priority option from the Priority list.
Priority options determine when queued build requests run. Requests with a High priority run before requests with Normal or Low priorities. Requests with Normal priority run before requests with Low priority. Normal is the default option.
Selected Enabled to make the trigger active.
Optional: If you selected Post-Processing Trigger, select a process from the Secondary Process list.
For information about schedules, see Creating schedules.
Click Save.

To see information about the teams that are assigned to the process and their permissions, click Security.