Function Compute:Manage pipelines

Pipeline configuration

Pipeline configuration includes four main items: trigger method, execution environment, resource description YAML, and DingTalk robot notification. You can configure the trigger method and execution environment when you create an application or environment. After creation, you can configure all four items by clicking the Edit button.

Pipeline trigger method

Application Center lets you customize the Git events that trigger pipelines. Application Center uses webhooks to receive Git events. When it receives an event that matches the trigger rules, it creates and runs a pipeline based on your configured pipeline YAML file. The supported trigger methods are:

• Branch trigger: The environment must be associated with a specified branch. Matches all Push events for the specified branch.

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

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

Pipeline execution environment

The Pipeline Execution Environment has two modes: Default Environment and Custom Environment.

Default execution environment

In the Default Environment, the platform fully manages the pipeline resources. Alibaba Cloud Function Compute covers the costs of pipeline execution, so you do not incur any fees. Each pipeline task runs in an independent sandboxed container. The platform ensures isolation of your pipeline execution environment. The default execution environment has the following limits:

• Instance resource specifications: 4 vCPU, 8 GB memory.

• Temporary disk space: 10 GB.

• Task execution timeout: 15 minutes.

• Region limits: Direct template deployment and GitHub code sources use the Singapore region outside China. Gitee, public GitLab, and Codeup use the China (Hangzhou) region.

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

Dedicated execution environment

The Custom Environment runs pipeline tasks in your account and provides more customization options. Based on your authorization, Application Center fully manages the tasks in the dedicated execution environment and schedules Function Compute instances in your account to run the pipelines in real time. Like the default execution environment, the dedicated execution environment is fully serverless. You do not need to manage the underlying infrastructure.

The Custom Environment provides the following customization options:

• Region and network: You can specify the region and VPC for the execution environment to enable scenarios such as accessing private network code repositories, artifact repositories, image repositories, and private Maven servers. For more information about supported regions, see Regions.

• Instance resource specifications: You can specify the CPU and memory specifications for the execution environment. For example, specify a larger instance to speed up builds.

  Note

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

• Persistent storage: You can specify NAS and OSS mount configurations. For example, mount a NAS file system for file caching to accelerate builds.

• Logs: You can specify an SLS project and Logstore for the persistence of 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.

YAML

Serverless Application Center is deeply integrated with the Serverless Devs developer tool. You can use the Serverless Devs resource description file to declare the resource configuration of your application. 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 instruction. In the following example, the specified resource description YAML file is demo.yaml, so 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 sample code runs the `s plan` command with the specified file if a resource description file is provided. Otherwise, it runs the `s plan` command with 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 Chatbot Notification Settings

After you enable this configuration, configure the DingTalk robot's Webhook address, signature key, notification rules, and custom messages. You can centrally manage the tasks that require notifications here, or you can enable notifications for each task separately through the pipeline YAML file. After you complete the overall notification configuration here, you can further refine the notification settings for each task in the Pipeline Details.

Pipeline environment variables

In the Pipeline Environment Variables section, click Modify, choose a method to configure the environment, complete the configuration as described below, and then click Deploy.

• Edit using the form (default)

  1. Click +Add Variable.

  2. Configure the key-value pair for the environment variable:

     • Variable: Custom.

     • Value: Custom.

• Edit using JSON format

  1. Click Edit in JSON Format.

  2. In the text box, enter the key-value pair in JSON format as follows.

     {
         "key": "value"
     }

     The following is an example.

     {
         "REGION": "MY_REGION",
         "LOG_PROJECT": "MY_LOG_PROJECT"
     }

The environment variables take effect in the Serverless Devs pipeline. You can reference them in `s.yaml` using ${env(key)} or in shell commands using $Key. The following is an example.

vars:
  region: ${env(REGION)}
  service:
    name: demo-service-${env(prefix)}
    internetAccess: true
    logConfig:
      project: ${env(LOG_PROJECT)}
      logstore: fc-console-function-pre
    vpcConfig:
      securityGroupId: ${env(SG_ID)}
      vswitchIds:
        - ${env(VSWITCH_ID)}
      vpcId: ${env(VPC_ID)}

Pipeline details

In the Pipeline Details section, you can configure the pipeline flow and specify detailed settings for tasks and their dependencies within the pipeline. The platform automatically generates a default pipeline flow, which you can edit.

Pipelines are managed using a YAML file. Two configuration methods are available: Hosting on Platform and Read from Repository .

Platform-hosted

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

Repository read

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 uses the pipeline YAML file from your specified Git repository to create and run the pipeline.

You can select Read from Repository above the Pipeline Details section and enter the name of the YAML file, as shown in the following figure.

The main part of the Pipeline Details section consists of the supporting tools area on the left and the YAML editing area on the right:

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

• Supporting tools area: Provides tools to assist with YAML editing, including the following:

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

  • Task Template: Provides a series of YAML templates for common tasks.

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

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

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

• The Reset button cancels all changes made since the last save and reverts to the 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 of the pipeline, making it easier to monitor its progress or troubleshoot issues.

Upgrade the pipeline build environment runtime

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