Configuring a Pipeline

Procedure

1. Log in to CodeArts Pipeline.
2. On the Pipelines tab page, search for the target pipeline, click in the Operation column, and click Edit.

   On the displayed page, you can configure the basic information (name and description), task orchestration, parameters, execution plans, permissions, and notifications.

3. Click Save.

Task Orchestration

On the Task Orchestration tab page, you can configure the code source, stages, jobs, and pass conditions.

• Configuring the code source

  Click the code source area. On the displayed dialog box, you can modify the code source.

• Managing a stage

  On the Task Orchestration tab page, click or Stage to add a stage to the pipeline. After a stage is added, you can edit, delete, clone, or move the stage.

  Table 1 Stage management

  Operation	Description
  Editing a stage	Click . In the displayed dialog box, you can configure the stage name and whether to always run the stage. NOTE: Always Run: If you select Yes, jobs in this stage will be executed and cannot be canceled. If you select No, jobs will be selected by default but can be deselected.
  Deleting a stage	Click and confirm the deletion as prompted.
  Cloning a stage	Click to clone a pipeline stage.
  Sorting stages	Click and drag to adjust the stage sequence.
  Setting admission	Click . In the displayed dialog box, configure the admission type. Automatic (default): The pipeline automatically proceeds to this stage. Manual: The pipeline can continue to run only after manual confirmation.

• Managing a job

  You can add jobs to each stage. After a job is added, you can edit, clone, delete, or move the job.

  Table 2 Job management

  Operation	Description
  Adding a job	Click Job to add a job to an empty stage. Click under a job to add a serial job. Click Parallel Job to add a parallel job. NOTE: Serial execution: Jobs are executed in sequence. For example, a build job and a deployment job must be executed sequentially. Parallel execution: Jobs are executed at the same time. For example, a code check job and a build job can be executed at the same time.
  Editing a job	Click a job card to edit the job.
  Cloning a job	Click on the job card to clone a serial job.
  Deleting a job	Click on the job card and confirm the deletion as prompted.
  Sorting jobs	Click, hold, and move a job card to adjust the sequence. NOTE: Job sequence cannot be adjusted when jobs are executed in parallel.

  When adding or editing a job, you can configure the job in the displayed dialog box.

  Table 3 Job configuration

  Operation	Description
  Adding an extension	There are five types of extensions: build, code check, deployment, test, and normal extensions. You can filter or search for extensions by type. Move the cursor to an extension card and click Add. Set parameters: Enter an extension name. Select a job to be called. If no proper job is available, create a job as prompted. If the called job has parameters, the parameters are displayed. Set the parameters. The extension name is followed by a flag. You can add only one extension with flag Job to a single job. Extensions with flag draft indicate that they are draft extensions. The extension for suspending a pipeline can only be added to stages that do not contain parallel jobs.
  Deleting an extension	Move the cursor to an extension card, click , and select Delete to delete the extension.
  Replacing an extension	Move the cursor to an extension card, click , and select Replace to replace the extension. Or, click Replace Extension above the extension name to choose another extension.
  Sorting extensions	Click, hold, and move an extension card to adjust the extension sequence.
  Job configuration	Set job ID, executor, and execution condition. The job ID should be unique. You can use the built-in executor or customize one. Built-in executor: provided by CodeArts Pipeline with out-of-the-box availability. Custom executor: allows you to configure tools and running environments as needed. Before using a custom executor, add an agent pool. For details, see Agent Pools. Execution conditions are the triggers for executing jobs in a pipeline. NOTE: You only need to configure executors for non-job-level extensions.

• Configuring pass conditions

  Click Pass Conditions under a stage. In the displayed dialog box, move the cursor to the pass conditions card and click Add, and then configure a policy for the pass conditions.

  • Only Pass-Conditions-of-Standard-Policies is available.
  • Policy: You can select a created policy.

    A policy is a set of rules. Each rule corresponds to a condition template of the output metric value in the extension. By predefining a policy, you can easily apply the same pass conditions to multiple pipelines. For details, see Rules and Policies.

    

    • You can set exclusive pass conditions for each stage.
    • You can set multiple pass conditions for one stage.

Setting Parameters

Switch to the Parameter Configuration tab page, and add parameters for the pipeline. For details, see Configuring Pipeline Parameters.

Pipeline parameters include custom and system-predefined parameters. The custom parameter types include string, enumeration, and auto-increment.

Configuring Execution Plans

Switch to the Execution Plan tab page, and configure trigger events, scheduled task, and parallel execution policy for a pipeline. Trigger events include code commit, merge request, and tag creation.

• Triggered upon code commits (Repo)

  The related pipeline is automatically executed when code is committed in an associated code repository, and the related branch and path of changed files meet inclusion and exclusion policies.

  • Branch inclusion: If the target branch to which the code is committed is included, the matching is successful.
  • Branch exclusion: If the target branch to which the code is committed is excluded, the matching fails.
  • Path inclusion: If any changed file (if path exclusion is configured, the changed file must not be excluded) is included, the matching is successful.
  • Path exclusion: If all changed files are excluded, the matching fails.

  

• Triggered upon merge requests (Repo)

  The related pipeline is automatically executed when there is an MR creation, updating, code updating, code merge, or MR reopening event in the associated code repository, and the related branch and path of changed files meet inclusion and exclusion policies.

  Event description:

  • Create: triggered upon MR creation.
  • Merge: triggered upon code merge. This event triggers code commit event.
  • Reopen: triggered upon MR reopening.
  • Update: triggered upon MR content, setting, or source code update. If you enable Code update at the same time, the pipeline will be triggered only upon source code update.

  Branch description:

  • Branch inclusion: If the target branch is included, the matching is successful.
  • Branch exclusion: If the target branch is excluded, the matching fails.
  • Path inclusion: If any changed file (if path exclusion is configured, the changed file must not be excluded) is included, the matching is successful.
  • Path exclusion: If all changed files are excluded, the matching fails.

  

• Triggered upon tag creation (Repo)

  The related pipeline is automatically executed when a tag is created in an associated code repository and the created tag meets inclusion and exclusion policies.

  • Tag inclusion: If the tag created in the code repository is included, the matching is successful.
  • Tag exclusion: If the tag created in the code repository is excluded, the matching fails.

  

• The branch is matched first, and then the path (if configured) is matched. If the matching is successful, the pipeline will be triggered.
• Branch exclusion takes precedence over branch inclusion. That is, when the target branch is included and excluded at the same time, the matching fails.
• Path exclusion takes precedence over path inclusion. That is, the excluded paths are matched first. If the included path is not configured, the matching is successful. If the included path is configured and any of the changed files is included, the matching is successful.
• Tag exclusion takes precedence over tag inclusion. That is, if a tag is included and excluded at the same time, the matching fails.

• Scheduled execution

  Click Create now to create a scheduled task. Turn on the Enable toggle, set the execution time and save the configuration. The pipeline will be executed at the specified time.

  

  

  You can create a maximum of 10 scheduled tasks.

• Parallel execution

  By default, five parallel executions are allowed in a pipeline. Excess instances will not be executed. Alternatively, you can change the maximum number of parallel instances (running and paused).

  Enable Parallel Execution, set the execution policy for extras, and active the policy by saving the configurations.

  

  Parameter	Description
  Parallel Instances	Maximum parallel instances, which vary by your purchases and packages.
  For Excess Instances	You can choose: Wait: Excess instances will wait for execution. You can view the queuing instances on the pipeline details page. Max. 100 queuing instances per pipeline. Instances will not be executed after 24 hours of waiting. You can manually cancel the waiting. Configurations of instances will not be changed once they enter the queue. Ignore: Excess instances will not be executed.

Managing Permissions

Switch to the Permissions tab page. You can configure role permissions and user permissions for the pipeline.

• If you retain the default role permissions, they are the same as those in the project settings.
• The permissions of the project creator and pipeline creator cannot be changed.
• User permissions take precedence over role permissions.
  

  By default, user permissions automatically synchronize with role permissions. If user permissions are configured, the user permissions overwrite the role permissions.

Role Permissions

You can click or to specify whether a role has permissions to view, execute, edit, and delete the pipeline.

User Permissions

You can click or to specify whether a user has permissions to execute, edit, and delete pipelines.

By default, a user with permissions to edit or execute pipelines can also view pipelines.

Notifications

Switch to the Notifications tab page and configure event notifications for the pipeline.

• Internal messages

  Pop-up notifications and emails will be sent to notify related personnel of pipeline activities (deleted, failed, succeeded, updated).

  Click to enable the notification or click to disable it.

  

  

  • By default, only pop-up notifications will be sent.
  • You can click in the upper right corner of the pipeline homepage to check notifications in the Notice dialog box.