How Baidu’s Tekes Actions Turns Pipelines into Code for Scalable CI/CD

Overview

Baidu App has built a mature DevOps workflow covering planning, development, testing, integration, and delivery. Continuous Integration (CI) is a core part of this workflow, supporting over 50 releases and 400,000 components and SDKs. However, different product lines require customized CI pipelines, which the existing templates cannot directly satisfy.

Pipeline as Code (PaC)

PaC treats a pipeline as source code, allowing product lines to describe required features in a structured language and automatically generate the corresponding pipeline. The concept follows the broader "as‑code" movement, similar to Infrastructure as Code (IaC).

Pipeline as code is a practice of defining deployment pipelines through source code, such as Git. It is part of a larger “as code” movement that includes infrastructure as code. Teams can configure builds, tests, and deployment in code that is trackable and stored in a centralized repository.

Like Ansible playbooks, Baidu encodes pipelines using a DSL that can be version‑controlled.

# playbook
- name: Install Xcode
  block:
    - name: check that the xcode archive is valid
      command: >
        pkgutil --check-signature {{ xcode_xip_location }} |
        grep "Status: signed Apple Software"
    - name: Clean up existing Xcode installation
      file:
        path: /Applications/Xcode.app
        state: absent
    - name: Install Xcode from XIP file Location
      command: xip --expand {{ xcode_xip_location }}
      args:
        chdir: /Applications
      poll: 5
      async: "{{ xcode_xip_extraction_timeout }}"
    - name: Accept License Agreement
      command: "{{ xcode_build }} -license accept"
      become: true
    - name: Run Xcode first launch
      command: "{{ xcode_build }} -runFirstLaunch"
      become: true
      when: xcode_major_version | int >= 13
  when: not xcode_installed or xcode_installed_version is version(xcode_target_version, '!=')

Using a DSL brings several benefits:

Product teams focus only on the current DSL version, simplifying maintenance.

Pipeline environment configuration becomes part of the DSL, eliminating configuration drift.

DSL snippets can be reused and composed as modular units.

Representative Solutions

The article compares two widely used PaC solutions:

Jenkins Pipeline

Jenkins 2.0 introduced a Groovy‑based DSL that unifies jobs and nodes into code.

// Jenkinsfile (Declarative Pipeline)
@Library('my-library') _
pipeline {
  agent { node { label 'MACOS' } }
  stages {
    stage('Checkout') {
      steps { checkout scm }
    }
    stage('Build') {
      steps { sh 'xcodebuild -workspace projectname.xcworkspace -scheme schemename -destination generic/platform=iOS' }
    }
    stage('UseMyLibrary') {
      steps { myCustomFunc 'Hello world' }
    }
  }
}

GitHub Actions

GitHub Actions uses a YAML DSL that lives in the repository.

# .github/workflows/ios.yml
name: iOS workflow
on: [push]
jobs:
  build:
    runs-on: macos-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Build
        run: xcodebuild -workspace projectname.xcworkspace -scheme schemename -destination generic/platform=iOS
      - name: UseMyLibrary
        uses: my-library/my-custom-action@master
        with:
          args: Hello world

Both DSLs are clear and interchangeable; the choice depends on the CI system used.

Tekes Actions

Tekes Actions is Baidu’s internal implementation, inspired by GitHub Actions but integrated with Baidu’s own CI platform (iPipe). It consists of three core components: Jobs, Events, and Runners.

Jobs : Tekes exposes reusable Actions that product lines can plug into their pipelines, enabling modular, component‑based CI.

Events : Custom event types trigger workflows; a separate orchestration service maps DSL files to product‑line specific triggers.

Runners : A self‑implemented executor interprets the DSL, schedules jobs, downloads Actions, runs scripts, and uploads logs. It can run locally via CLI or on a VM cluster via the iPipe Agent.

Typical Tekes Actions workflow (iOS component publish) is defined in a YAML file:

# baiduapp/ios/publish.yml
name: 'iOS Module Publish Workflow'
author: 'zhuyusong'
description: 'iOS component publish workflow'
on:
  events:
    topic_merge:
      branches: ['master', 'release/**']
      repositories: ['baidu/baidu-app/*', 'baidu/third-party/*']
jobs:
  publish:
    name: 'publish modules using Easybox'
    runs-on: macos-latest
    steps:
      - name: 'Checkout'
        uses: actions/checkout@v2
      - name: 'Setup Easybox'
        uses: actions/setup-easybox@v2
        with:
          is_public_storage: true
      - name: 'Build Task use Easybox'
        uses: actions/easybox-ios-build@v1
        with:
          component_check: true
          quality_check: true
      - name: 'Publish Task use Easybox'
        uses: actions/easybox-ios-publish@v1
      - name: 'Access Task use Easybox'
        uses: actions/easybox-ios-access@v1

Tekes Actions adopts GitHub‑style DSL because its componentized workflow aligns well with Baidu’s CI ecosystem.

Tekes Runner Architecture

The Runner is a serverless service built on Baidu Cloud. It includes three modules:

Template : Reads and validates DSL files.

Worker : Manages workflow execution and state machines.

WebAPI (optional): Persists logs and context to a logging service.

Runner commands (CLI) include run, pause, unpause, and kill, managing the lifecycle of a workflow.

When run is invoked, the Runner initializes the workflow, creates a finite‑state‑machine (FSM) for each job, and transitions them through initialized → running → stopped. If a job fails, the FSM still reaches a stopped state; external kill or timeout also force a stop.

Action‑Runner Interaction Details

Three interaction mechanisms are used:

Environment variables : Runner injects inputs and context as env vars.

Workspace files : Runner places intermediate artifacts in the workspace for Actions to consume.

Special print commands : Actions emit specially‑prefixed log lines that the Runner parses to set outputs, upload artifacts, or log messages.

Pause/Unpause and WebAPI

Long‑running manual approvals are handled by pause, which persists the current context and terminates the process. unpause restores the context and resumes execution.

Because most Runners execute on remote VMs managed by iPipe Agent, the WebAPI service stores logs and persisted context, enabling later retrieval and debugging.

Conclusion

Pipeline as Code provides a flexible, scalable way to manage CI/CD pipelines. By leveraging a DSL, reusable Actions, and a custom runner, Baidu’s Tekes Actions demonstrates how internal DevOps platforms can achieve the same benefits as public solutions while remaining tightly integrated with existing infrastructure.