Cloud Native Build is repository-centric, using configuration files to describe what tasks to execute when certain events occur on specific branches.

Let's start with a simple example, showing step by step how to create a repository and trigger a pipeline.

Then, we'll use a common development requirement - Pull Request pipeline checks - as a target to demonstrate how to write configuration files step by step.

Based on this, you can select specific scenario repositories from Best Practices, fork the repository or copy its configuration files to write pipeline configurations that meet your needs.

Writing Your First Pipeline

1. Create Repository

Create a new repository (skip if you have one). After creation, you can click the Workspaces button to quickly create a development environment.

workspace

Select WebIDE to enter the development interface for convenience.

choose-ide

2. Write .cnb.yml Configuration File

Here's a simple pipeline configuration:

# Branch name
main:
  # Event name
  push:
    # Tasks to execute
    - stages:
        - name: echo
          script: echo "hello world"

Add the CI configuration file .cnb.yml, copy this content into the configuration file, commit and push to the remote main branch.

add-ci

This will trigger the pipeline build.

3. View Build Details

Click Cloud Native Build on the repository page to see the build list.

pipeline-push

The latest one is the push event pipeline just triggered. Click to see build details.

Configuration Explanation

Next, let's use a common pipeline requirement to explain the configuration file syntax:

"Requirement: When there's a Pull Request to the main branch, trigger a pipeline to perform lint and test checks, and send notifications if they fail."

Let's analyze this requirement and extract some key elements:

1. Main branch, like main.
2. Repository event, i.e., pull_request event.
3. Pipeline tasks:
   1. lint
   2. test
4. Tasks on failure:
   1. notify

Now let's write the .cnb.yml configuration file step by step based on these elements.

First layer property is the branch name:

#Branch name
main:

Build triggers when branch has pull_request event:

#Branch name
main:
  # Event name
  pull_request:

Events can execute multiple pipelines (in parallel), and pipelines have multiple tasks (serial or parallel).

Here we simplify, with only one pipeline under the event:

#Branch name
main:
  # Event name
  pull_request:
    # Array type indicates multiple pipelines possible
    - name: pr-check
      stages:

Including two serial tasks: lint and test.

#Branch name
main:
  # Event name
  pull_request:
    # Array type indicates multiple pipelines possible
    - name: pr-check
      # Multiple tasks under pipeline
      stages:
        # Tasks to execute
        - name: lint
          script: echo "lint job"
        - name: test
          script: echo "test job"

If it fails, we need to send notifications. Besides stages representing expected tasks, pipelines also have failStages representing tasks to execute when stages tasks fail:

#Branch name
main:
  # Event name
  pull_request:
    # Array type indicates multiple pipelines possible
    - name: pr-check
      # Multiple tasks under pipeline
      stages:
        - name: lint
          script: echo "lint job"
        - name: test
          script: echo "test job"
      # Tasks to execute when stages fail
      failStages:
        - name: lint
          script: echo "notify to some chat group"

To summarize, a pipeline's execution process is:

1. Repository event occurs
2. Determine branch
3. Determine event name
4. Execute pipeline
5. Execute tasks
6. Tasks on failure

To learn more about configuration file usage, please see Configuration File.

Syntax Guide

For detailed configuration file syntax, please see Grammar.

Best Practices

For more complete examples, refer to Best Practices.