Managing secondary processes

Secondary processes manipulate or operate on the artifacts that build processes generate.

Before you create a secondary process, complete these actions:
The artifacts that build processes generate are stored in CodeStation and are available for more processing, which is called secondary processing. Most secondary processes run tests on build artifacts.
  1. From the IBM® UrbanCode™ Build dashboard, click Projects, and then use the expand icon that is associated with a project to display the project's build processes.
  2. Select a build process, and click Configuration.
  3. Click New in the Secondary Process area.
  4. 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.
    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. After a process begins, it is not suspended or stopped when a higher-priority process is requested. Normal is the default option.
    6. Click Save.
  5. 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.
  6. Define a trigger by completing these steps:
    1. Click Triggers, and then click New Trigger.
    2. 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.
    3. Type a name for the trigger in the Name list.
    4. Optional: If you selected Scheduled Trigger, select a schedule from the Schedule list.
      For information about schedules, see Creating schedules.
    5. Select Force to force builds when triggers occur.
      If Force is selected, builds are triggered even if source changes are not detected.
    6. 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.
    7. Selected Enabled to make the trigger active.
    8. Optional: If you selected Post-Processing Trigger, select a process from the Secondary Process list.
      For information about schedules, see Creating schedules.
    9. Click Save.
To see information about the teams that are assigned to the process and their permissions, click Security.