await-resolve

• cnb:await
• cnb:resolve

await waits for the execution of resolve, and resolve can pass variables or files to await.

With await-resolve, multiple concurrent pipelines can cooperate with each other to achieve more flexible sequential control.

TIP

Difference between await-resolve and apply or trigger:

The former refers to waiting for the corresponding resolve notification when a pipeline executing the await task reaches the await task.

The latter refers to triggering a new event in a pipeline and starting a new build. It can cross repositories and can be called asynchronously or synchronously.

• Usage Limitations
• Deadlock Detection
• Applicable Events
• await Parameters
• resolve Parameters
• Output Results
• Configuration Examples

Usage Limitations

1. await and resolve operations can only be performed on pipelines triggered by the same event.
2. A key can only be resolved once, but it can be awaited multiple times.
3. await and resolve can be grouped using a key.

Deadlock Detection

await and resolve can be used together to achieve flexible flow control, but they can also introduce more complex edge cases, such as:

1. pipeline-1 and pipeline-2 awaiting each other, resulting in a deadlock.
2. await loop between multiple pipelines, resulting in an indirect deadlock.
3. Awaiting a non-existent key or a key that is not associated with a resolve, resulting in an infinite wait.
4. The resolve task fails, causing the corresponding await to be stuck in an infinite wait.
5. Multiple resolve tasks associated with the same key, resulting in an exception.

The deadlock detection mechanism automatically detects the above exceptions, terminates the waiting state of await, and throws a dead lock found. exception.

The order of await and resolve in the configuration file does not affect the execution result. The last await task will always wait for the corresponding resolve to complete, and this situation will not be terminated by the deadlock detection mechanism.

Applicable Events

all

await Parameters

• key

key

• type: String
• required: true

Pairing ID

resolve Parameters

• key
• data

key

• type: String
• required: true

Pairing ID

data

• type: object
• required: false

The object to be passed.

In the key:value format, supports multiple levels. Example:

- name: resolve a json
  type: cnb:resolve
  options:
    key: demo
    data:
      a: 1
      b:
        c: 2

The result of the await task is the data object declared in the resolve task.

You can access this object through exports. Example:

- name: await a json
  type: cnb:await
  options:
    key: demo
  exports:
    a: VAR_A
    b.c: VAR_B
- name: show var
  script:
    - echo ${VAR_A}    # 1
    - echo ${VAR_B}    # 2

Certainly, you can also pass an empty task without any content, just to indicate a waiting action.

- name: ready
  type: cnb:resolve
  options:
    key: i-am-ready

- name: ready
  type: cnb:await
  options:
    key: i-am-ready

Output Results

{
  // Data returned by resolve
  data
}

Configuration Examples

• Transfer Files

main:
  push:
    - runner:
        tags: cnb:arch:arm64:v8
      stages:
        - name: show Architecture
          script: lscpu | grep Architecture
        - name: hello
          script:
            - echo hello
            - mkdir ./files/
            - touch ./files/hello
        - name: resolve hello
          type: cnb:resolve
          options:
            key: u-nide-kuaidi
            dist: files
    - runner:
        tags: cnb:arch:amd64
      stages:
        - name: show Architecture
          script: lscpu | grep Architecture
        - name: await hello
          type: cnb:await
          options:
            key: u-nide-kuaidi
        - name: show files
          script: ls -l files