Help Center> CodeArts Pipeline> User Guide> Pipelines> Configuring a Pipeline
Updated on 2024-05-08 GMT+08:00

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 plan, permissions, and notifications.

  3. Click Save.

Task Orchestration

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

  • Configuring a pipeline source

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

  • Managing a stage

    On the Task Orchestration tab page, click or to add a stage to the pipeline. After a stage is added, you can edit, delete, copy, 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 the stage is always run.

    NOTE:

    Always Run: If you select Yes, jobs in this stage will be executed and cannot be canceled. If you select No, jobs are selected by default but can be deselected.

    Deleting a stage

    Click and confirm the deletion as prompted.

    Copying a stage

    Click to copy a pipeline stage.

    Sorting stages

    Click to adjust the stage sequence.

    Setting stage entry

    Click . In the displayed dialog box, configure the entry type.

    • Automatic (default): The pipeline automatically enters this stage and continues to run.
    • 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, copy, delete, or move the job.

    Table 2 Job management

    Operation

    Description

    Adding a job

    • Click to add a job to an empty stage.
    • Click under a job to add a serial job.
    • Click 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.

    Copying a job

    Click on the job card to copy a serial job.

    Deleting a task

    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 invoked job has parameters, the parameters are displayed. Set the parameters.
    • The extension name is followed by a flag. Only one extension with flag Job can be added 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 and click and select Delete to delete the extension.

    Sorting extensions

    Click, hold, and move an extension card to adjust the extension sequence.

    Job configuration

    Job ID, executor, and execution condition need to be set.

    • 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 the ExecuteShellCommand extension and custom extensions.

  • Configuring pass conditions

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

    • Currently, only standard policy pass conditions can be added.
    • Policy: Configure policies for pass conditions. You can select those already created for the current project or tenant.

      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.

      • Pass conditions can be set exclusively for each stage of a pipeline and is valid only for the corresponding stage.
      • Multiple pass conditions can be configured for one stage.

Setting Parameters

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

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

Configuring an Execution Plan

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 an MR creation.
    • Update: triggered upon MR content, setting, or source code update.
    • Code update: triggered upon source code update.
    • Merge: triggered upon code merge. This event triggers code commit event.
    • Reopen: triggered upon an MR reopening.

    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 (CodeArts 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 is 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 the role permissions are not changed, 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 pipelines.

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. When a pipeline is deleted, failed, succeeded, or edited, you can configure pop-up notifications and email to notify related personnel.

Click to enable the notification or click to disable it.

  • By default, pop-up notifications are sent, and email notifications are not sent.
  • You can click in the upper right corner of the pipeline homepage and view the notification messages on the Notice dialog box.