Function Compute:Manage pipelines

Pipeline configuration

Pipeline configuration includes four main items: pipeline trigger method, pipeline execution environment, resource description YAML, and DingTalk robot notifications. You can configure the pipeline trigger method and execution environment when you create an application or environment. After creation, you can click the edit button to configure all four items.

Pipeline trigger methods

Serverless Application Center lets you customize the Git events that trigger a pipeline. Serverless Application Center uses a webhook to receive Git events. When it receives an event that matches the trigger rules, it creates and runs the pipeline according to your pipeline YAML configuration. The following trigger methods are supported:

• Branch trigger: The environment must be associated with a specific branch. This matches all Push events in the specified branch.

• Tag trigger: Matches all Tag creation events for a specified Tag expression.

• Branch merge trigger: Matches Merge/Pull Request events from a specified source branch to the target branch associated with the environment.

Pipeline execution environment

Pipeline execution environment is available in two modes: default execution environment and dedicated execution environment.

Default execution environment

In the default execution environment, the platform fully manages the pipeline resources. Alibaba Cloud Function Compute covers the costs incurred during pipeline execution, so you do not need to pay any fees. Each pipeline task runs in an independent, sandboxed container, and the platform ensures the security and isolation of your pipeline execution environment. The limits of the default execution environment are as follows:

• Instance specifications: 4 vCPU, 8 GB memory.

• Temporary disk space: 10 GB.

• Task execution timeout: 15 minutes.

• Region limits: For direct deployment from templates or from a GitHub source, use the Singapore region. For Gitee, public GitLab, or Codeup sources, use the China (Hangzhou) region.

• Network limits: Fixed IP addresses and CIDR blocks are not supported. Accessing specific websites using an IP address whitelist is not supported. Accessing resources within your VPC is not supported.

Dedicated execution environment

A dedicated execution environment runs pipeline tasks under your account and provides more customization options. Based on your authorization, Serverless Application Center fully manages the tasks in the dedicated execution environment and schedules Function Compute instances in real time to run the pipeline under your account. Similar to the default execution environment, the dedicated execution environment is fully serverless, which means you do not need to manage the underlying infrastructure.

A dedicated execution environment provides the following customization options:

• Region and network: You can specify the execution environment's region and VPC. This lets you access resources such as private code repositories, artifact repositories, image repositories, and private Maven servers. For more information about the supported regions, see Service endpoints.

• Instance specifications: You can specify the CPU and memory specifications for the execution environment. For example, specify an instance with higher specifications to speed up builds.

  Note

  The ratio of vCPU cores to memory in GB must be between 1:1 and 1:4.

• Persistent storage: You can configure NAS and OSS mount settings. For example, use a NAS mount for file caching to accelerate builds.

• Logs: You can specify an SLS project and Logstore to enable persistence for pipeline execution logs.

• Timeout: You can customize the execution timeout for pipeline tasks. The default is 600 seconds, and the maximum is 86,400 seconds.

Resource description YAML

Serverless Application Center is deeply integrated with the Serverless Devs developer tool. You can use a Serverless Devs resource description file to declare your service's resource configuration. For more information about the YAML specification, see Serverless Devs YAML specification. The default resource description file is named s.yaml, but you can specify a different file name. After you specify a resource description file, you can use it in the pipeline in two ways:

• When you use the @serverless-cd/s-deploy deployment plugin, the plugin automatically uses the specified resource description file for deployment. This works by adding the -t/--template command to the Serverless Devs operation. For example, in the following code, the specified resource description YAML file is demo.yaml. The command executed by the plugin is s deploy -t demo.yaml.

- name: deploy
  context:
    data:
      deployFile: demo.yaml
      steps:
      - plugin: '@serverless-cd/s-setup'
      - plugin: '@serverless-cd/checkout'
      - plugin: '@serverless-cd/s-deploy'
  taskTemplate: serverless-runner-task

• When you use a script for execution, you can reference the specific resource description file name with ${{ ctx.data.deployFile }}. For example, the following code runs the s plan command using the specified file if one is provided. Otherwise, it runs the s plan command using the default s.yaml file.

- name: pre-check
  context:
    data:
      steps:
      - run: s plan -t ${{ ctx.data.deployFile || s.yaml }}
      - run: echo "s plan finished."
  taskTemplate: serverless-runner-task

DingTalk robot notifications

After you enable this configuration, you must configure the DingTalk robot's Webhook address, Signing key, notification rules, and Custom message. You can manage all tasks that require notifications here, or you can enable notifications for each task separately in the pipeline YAML. After you complete the overall notification configuration here, you can further refine the notification settings for each task in the Pipeline details section.

Pipeline details

In the Pipeline details section, you can configure the pipeline flow and specify the details of tasks and their relationships. The platform automatically generates a default pipeline flow, which you can edit.

Pipelines are managed using YAML. Two configuration methods are available: Platform-hosted and Read from repository:

Platform-hosted

By default, the pipeline YAML is hosted by the platform. This means the configuration is managed centrally on the platform and takes effect at the next deployment after an update.

Read from repository

The pipeline's YAML description file is stored in a remote Git repository. After you edit and save it in the console, the platform commits the changes to your Git repository in real time. This commit does not trigger a pipeline execution. When an event in your code repository triggers a pipeline, the platform creates and runs the pipeline using the YAML file from your specified Git repository.

In the upper part of the Pipeline details section, you can specify Read from repository and enter the YAML file name, as shown in the following figure.

The main body of the Pipeline details section consists of the auxiliary tools area on the left and the YAML editing area on the right:

• YAML editing area: You can directly edit the pipeline YAML to modify the pipeline flow. For more information, see Describe a pipeline using a YAML file.

• Auxiliary tools area: This provides tools to help you edit the YAML. It includes:

  • Flow preview: Provides a visual preview and simple editing capabilities for the pipeline flow.

  • Task templates: Provides a series of commonly used task YAML templates.

In the upper-right corner of the section are three buttons: Save, Full screen, and Reset:

• The Save button saves the changes made to the YAML on the page and syncs them to the pipeline YAML.

• The Full screen button expands the main editing area to full screen.

• The Reset button cancels all changes made since the last time the YAML was saved, reverting it to its initial state.

View pipeline execution history

You can click a specific pipeline execution version to view its details. This information lets you quickly check the execution logs and status, which helps you understand the pipeline's execution or troubleshoot problems.

Upgrade the pipeline build environment runtime

You can set the pipeline runtime version using the pipeline runtime-setup plugin or by modifying the environment variables in the resource description file.