eve-pipelines-workflows

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Eve Pipelines and Workflows

Eve 流水线与工作流

Use these patterns to automate build and deploy actions and invoke workflow jobs.

使用这些模式来自动化构建、部署操作以及调用工作流任务。

Pipelines (v2 steps)

流水线（v2 步骤）

Define pipelines under
```
pipelines
```
in
```
.eve/manifest.yaml
```
.
Steps can be
```
action
```
,
```
script
```
, or
```
agent
```
.
Use
```
depends_on
```
to control ordering.
Built-in actions include
```
build
```
,
```
release
```
,
```
deploy
```
,
```
run
```
,
```
job
```
,
```
create-pr
```
.

Run manually:

```
eve pipeline list
```
```
eve pipeline show <project> <name>
```

eve pipeline run <name> --ref <sha> --env <env> --repo-dir ./my-app

Trigger blocks exist in the manifest; GitHub and Slack webhooks can create pipeline runs.

在
```
.eve/manifest.yaml
```
的
```
pipelines
```
字段下定义流水线。
步骤类型可以是
```
action
```
、
```
script
```
或
```
agent
```
。
使用
```
depends_on
```
控制步骤执行顺序。
内置操作包括
```
build
```
、
```
release
```
、
```
deploy
```
、
```
run
```
、
```
job
```
、
```
create-pr
```
。

手动运行命令：

```
eve pipeline list
```
```
eve pipeline show <project> <name>
```

eve pipeline run <name> --ref <sha> --env <env> --repo-dir ./my-app

清单文件中包含触发器配置块；GitHub和Slack的webhook可触发流水线运行。

Built-in Actions

内置操作

build

action

build

操作

Build actions create BuildSpec and BuildRun records that are tracked and observable:

Creates BuildSpec (defines what to build) and BuildRun (execution record) in the database
Outputs include
```
build_id
```
and
```
image_digests
```
map (service name to SHA256 digest)
These outputs automatically flow to dependent steps (release uses build_id)

Inspect builds independently:

eve build show

eve build diagnose

eve build runs

eve build logs

Build操作会创建可追踪、可观测的BuildSpec和BuildRun记录：

在数据库中创建BuildSpec（定义构建内容）和BuildRun（执行记录）
输出包含
```
build_id
```
和
```
image_digests
```
映射表（服务名称到SHA256摘要的对应关系）
这些输出会自动传递给依赖步骤（release操作会使用build_id）

可独立查看构建信息：

eve build show

、

eve build diagnose

、

eve build runs

、

eve build logs

Agent steps

Agent 步骤

Use

agent

steps when a pipeline stage should run an AI agent job:

yaml

pipelines:
  remediation:
    steps:
      - name: analyze
        agent:
          prompt: "Analyze the failure and propose a fix"

当流水线阶段需要运行AI Agent任务时，使用

agent

步骤：

yaml

pipelines:
  remediation:
    steps:
      - name: analyze
        agent:
          prompt: "Analyze the failure and propose a fix"

Canonical pipeline flow

标准流水线流程

Every deploy pipeline should follow this pattern:

yaml

pipelines:
  deploy:
    steps:
      - name: build
        action:
          type: build
          # Creates BuildSpec + BuildRun, outputs build_id + image_digests
      - name: release
        depends_on: [build]
        action:
          type: release
          # References build_id, derives digests from BuildArtifacts
      - name: deploy
        depends_on: [release]
        action:
          type: deploy
          env_name: staging
          # Uses digest-based image refs for immutable deploys

每个部署流水线都应遵循以下模式：

yaml

pipelines:
  deploy:
    steps:
      - name: build
        action:
          type: build
          # 创建BuildSpec + BuildRun，输出build_id + image_digests
      - name: release
        depends_on: [build]
        action:
          type: release
          # 引用build_id，从BuildArtifacts中获取镜像摘要
      - name: deploy
        depends_on: [release]
        action:
          type: deploy
          env_name: staging
          # 使用基于摘要的镜像引用实现不可变部署

Promotion workflow

制品晋升流程

Build once in test, then promote the same build artifacts to staging/production:

The build step creates a BuildRun with artifacts (image digests)
Releases carry the build_id forward, ensuring identical images across environments
This pattern guarantees you deploy exactly what you tested

Track pipeline execution:

bash

eve job list --phase active
eve job follow <job-id>
eve job result <job-id>

在测试环境中构建一次，然后将相同的构建制品晋升到预发布/生产环境：

Build步骤会创建包含制品（镜像摘要）的BuildRun
Release操作会携带build_id，确保不同环境使用完全相同的镜像
该模式保证你部署的内容与测试的完全一致

追踪流水线执行：

bash

eve job list --phase active
eve job follow <job-id>
eve job result <job-id>

Pipeline Logs & Streaming

流水线日志与流式输出

Monitor pipeline runs in real time:

bash

undefined

实时监控流水线运行：

bash

undefined

Snapshot logs for a run

获取某次运行的日志快照

eve pipeline logs <pipeline> <run-id>

Real-time SSE streaming

实时SSE流式输出

eve pipeline logs <pipeline> <run-id> --follow

Stream specific step

流式输出指定步骤的日志

eve pipeline logs <pipeline> <run-id> --follow --step <name>


Failed steps include failure hints and link to build diagnostics when applicable.

eve pipeline logs <pipeline> <run-id> --follow --step <name>


失败步骤会包含失败提示，必要时会链接到构建诊断信息。

Environment Deploy as Pipeline Alias

环境部署作为流水线别名

When an environment has a

pipeline

configured in the manifest,

eve env deploy <env> --ref <sha>

automatically triggers that pipeline instead of doing a direct deploy.

当清单文件中为某个环境配置了

pipeline

时，

eve env deploy <env> --ref <sha>

会自动触发该流水线，而非直接执行部署。

Basic usage

基础用法

bash

undefined

bash

undefined

Triggers the configured pipeline for test environment

触发测试环境的配置流水线

eve env deploy test --ref 0123456789abcdef0123456789abcdef01234567

Pass inputs to the pipeline

向流水线传递输入参数

eve env deploy staging --ref 0123456789abcdef0123456789abcdef01234567 --inputs '{"release_id":"rel_xxx"}'

Bypass pipeline and do direct deploy

绕过流水线，执行直接部署

eve env deploy staging --ref 0123456789abcdef0123456789abcdef01234567 --direct

undefined

eve env deploy staging --ref 0123456789abcdef0123456789abcdef01234567 --direct

undefined

Promotion flow example

制品晋升流程示例

bash

undefined

bash

undefined

1. Build and deploy to test environment

1. 构建并部署到测试环境

eve env deploy test --ref 0123456789abcdef0123456789abcdef01234567

2. Get release info from the test build

2. 从测试构建中获取发布信息

eve release resolve v1.2.3

Output: rel_xxx

输出：rel_xxx

3. Promote to staging using the release_id

3. 使用release_id将制品晋升到预发布环境

eve env deploy staging --ref 0123456789abcdef0123456789abcdef01234567 --inputs '{"release_id":"rel_xxx"}'

undefined

eve env deploy staging --ref 0123456789abcdef0123456789abcdef01234567 --inputs '{"release_id":"rel_xxx"}'

undefined

Key behaviors

核心特性

environments.<env>.pipeline

is set,

eve env deploy <env>

triggers that pipeline

Use
```
--direct
```
flag to bypass the pipeline and perform a direct deploy
Use
```
--inputs '{"key":"value"}'
```
to pass inputs to the pipeline run
Default inputs can be configured via
```
environments.<env>.pipeline_inputs
```
in the manifest
The
```
--ref
```
flag specifies which git SHA to deploy (40-character SHA or ref resolved via
```
--repo-dir
```
)
Environment variables and secrets are interpolated as usual

This pattern enables promotion workflows where you build once in a lower environment and promote the same artifact through higher environments.

如果配置了

environments.<env>.pipeline

，

eve env deploy <env>

会触发对应的流水线

使用
```
--direct
```
标志可绕过流水线，执行直接部署
使用
```
--inputs '{"key":"value"}'
```
向流水线运行传递输入参数
可通过清单文件中的
```
environments.<env>.pipeline_inputs
```
配置默认输入参数
```
--ref
```
标志指定要部署的Git SHA（40位SHA或通过
```
--repo-dir
```
解析的引用）
环境变量和密钥会按常规方式插值注入

该模式支持制品晋升工作流：在低环境中构建一次，然后将相同的制品推送到更高层级的环境。

Workflows

工作流

Define workflows under
```
workflows
```
in the manifest.
```
db_access
```
is honored when present (
```
read_only
```
,
```
read_write
```
).
Invocation
```
resource_refs
```
are available to every workflow step by default, including dependent steps. Use workflow-level
```
resource_refs
```
to set a default policy and step-level
```
resource_refs
```
to override it:
- ```
inherit
```
  /
```
all
```
  : pass all invocation refs.
- ```
none
```
  : pass no refs.
- ```
[brief, design-system]
```
  : pass only matching ref
```
name
```
  ,
```
label
```
  ,
```
mount_path
```
  ,
```
uri
```
  , or
```
metadata.name
```
  .

Invoke manually:

```
eve workflow list
```
```
eve workflow show <project> <name>
```

eve workflow run <project> <name> --input '{"k":"v"}'

(fire-and-forget)

eve workflow invoke <project> <name> --input '{"k":"v"}'

(wait for result)

```
eve workflow logs <job-id>
```

Invocation creates a job; track it with normal job commands.

在清单文件的
```
workflows
```
字段下定义工作流。
如果存在
```
db_access
```
配置，会遵循其权限设置（
```
read_only
```
、
```
read_write
```
）。
调用时的
```
resource_refs
```
默认对所有工作流步骤可用，包括依赖步骤。使用工作流级别的
```
resource_refs
```
设置默认策略，使用步骤级别的
```
resource_refs
```
进行覆盖：
- ```
inherit
```
  /
```
all
```
  ：传递所有调用引用。
- ```
none
```
  ：不传递任何引用。
- ```
[brief, design-system]
```
  ：仅传递匹配
```
name
```
  、
```
label
```
  、
```
mount_path
```
  、
```
uri
```
  或
```
metadata.name
```
  的引用。

手动调用命令：

```
eve workflow list
```
```
eve workflow show <project> <name>
```

eve workflow run <project> <name> --input '{"k":"v"}'

（触发后无需等待结果）

eve workflow invoke <project> <name> --input '{"k":"v"}'

（等待执行结果）

```
eve workflow logs <job-id>
```

调用会创建一个任务；可使用常规任务命令追踪其状态。

Workflow Hints

工作流提示

Control gating, timeouts, and harness preferences via

hints

yaml

workflows:
  remediate:
    hints:
      gates: ["remediate:proj_abc123:staging"]

通过

hints

控制门限、超时和harness偏好：

yaml

workflows:
  remediate:
    hints:
      gates: ["remediate:proj_abc123:staging"]

Conditional Steps

条件步骤

Skip a downstream step based on an upstream's outcome. Conditions reference named upstream steps and resolve at dispatch time:

yaml

workflows:
  triage-and-act:
    steps:
      - name: triage
        agent: { prompt: "Classify this incident" }
      - name: deep
        depends_on: [triage]
        condition: "triage.status == 'complex'"   # skip if false
        agent: { prompt: "Run deep analysis" }

Conditions support

==

and

!=

against upstream step status. Referenced steps must appear in

depends_on

— validation rejects ghost references and bad condition syntax at manifest sync.

根据上游步骤的结果跳过下游步骤。条件引用已命名的上游步骤，在调度时解析：

yaml

workflows:
  triage-and-act:
    steps:
      - name: triage
        agent: { prompt: "Classify this incident" }
      - name: deep
        depends_on: [triage]
        condition: "triage.status == 'complex'"   # 条件为false时跳过
        agent: { prompt: "Run deep analysis" }

条件支持针对上游步骤状态的

==

和

!=

判断。被引用的步骤必须出现在

depends_on

中——清单同步时会验证是否存在无效引用或错误的条件语法。

Step-Level Harness Overrides

步骤级Harness覆盖

Pin or override harness per step (workflow steps and pipeline steps share the same shape):

yaml

steps:
  - name: classify
    harness: claude
    harness_profile: claude-sonnet
    harness_options:
      model: claude-sonnet-4-7
      reasoning_effort: medium
      temperature: 0.2
    agent: { prompt: "Classify this" }

Step-level values take precedence over agent-resolved defaults.

harness_profile

may carry a template like

${inputs.model}

for caller-driven selection.

为单个步骤固定或覆盖harness配置（工作流步骤和流水线步骤结构相同）：

yaml

steps:
  - name: classify
    harness: claude
    harness_profile: claude-sonnet
    harness_options:
      model: claude-sonnet-4-7
      reasoning_effort: medium
      temperature: 0.2
    agent: { prompt: "Classify this" }

步骤级配置优先级高于Agent解析的默认值。

harness_profile

可包含模板（如

${inputs.model}

），由调用者驱动选择。

Workflow

env_overrides

工作流

env_overrides

Set env at three layers — workflow, step, invocation — and the runtime merges them in that order (later wins). Reference secrets with

${secret.KEY}

; the resolver redacts them in logs.

yaml

workflows:
  remediate:
    env_overrides:
      LOG_LEVEL: info
    steps:
      - name: act
        env_overrides:
          LOG_LEVEL: debug          # step wins over workflow
          API_KEY: ${secret.VENDOR_TOKEN}
        agent: { prompt: "Remediate" }

Callers add a third layer at invoke time:

bash

eve workflow invoke <project> remediate --input '{"k":"v"}' --env-override DRY_RUN=true

Pipeline

env

propagates down to the run's

env_name

so steps see the right scope without re-declaring it.

可在三个层级设置环境变量——工作流、步骤、调用——运行时会按该顺序合并（后续层级覆盖前面的）。使用

${secret.KEY}

引用密钥；解析器会在日志中自动脱敏。

yaml

workflows:
  remediate:
    env_overrides:
      LOG_LEVEL: info
    steps:
      - name: act
        env_overrides:
          LOG_LEVEL: debug          # 步骤级配置覆盖工作流级
          API_KEY: ${secret.VENDOR_TOKEN}
        agent: { prompt: "Remediate" }

调用者可在调用时添加第三层级的配置：

bash

eve workflow invoke <project> remediate --input '{"k":"v"}' --env-override DRY_RUN=true

流水线的

env

会向下传递到运行的

env_name

，因此步骤无需重新声明即可看到正确的作用域。

Per-Job Harness Override (Ad-Hoc Jobs)

单任务Harness覆盖（临时任务）

When firing an ad-hoc job (outside a workflow), override the harness on the create call:

bash

eve job create --description "Investigate" \
  --harness claude \
  --profile claude-sonnet

当触发临时任务（工作流之外）时，可在创建调用时覆盖harness配置：

bash

eve job create --description "Investigate" \
  --harness claude \
  --profile claude-sonnet

Or pass a full override object:

或传递完整的覆盖配置文件：

eve job create --description "..." --harness-override-file ./override.json

override.json: { "harness": "...", "model": "...", "reasoning_effort": "...", "variant": "...", "temperature": 0.2 }


The override flows end-to-end through dispatch and claim, taking precedence over agent-resolved values.


该覆盖配置会贯穿调度和认领流程，优先级高于Agent解析的默认值。

Slack Notifications, Retry, and File Refs

Slack通知、重试与文件引用

Workflow
```
hints.slack
```
posts step start/complete/fail to a configured channel.

Retry the failed/upstream-failed tail of a previous invocation:

eve workflow retry <root-job-id> --failed

eve workflow retry <root-job-id> --from <step>

Workflow steps accept file references (
```
resource_refs
```
entries that point at a path) — they materialize into the step's workspace alongside other refs.

工作流
```
hints.slack
```
可将步骤的启动/完成/失败状态发布到配置的频道。

重试之前调用中失败/上游失败的后续步骤：

eve workflow retry <root-job-id> --failed

eve workflow retry <root-job-id> --from <step>

工作流步骤支持文件引用（指向路径的
```
resource_refs
```
条目）——它们会和其他引用一起在步骤的工作区中实例化。

eve-pipelines-workflows

Original

Translation

Eve Pipelines and Workflows

Eve 流水线与工作流

Pipelines (v2 steps)

流水线（v2 步骤）

Built-in Actions

内置操作

build action

build 操作

Agent steps

Agent 步骤

Canonical pipeline flow

标准流水线流程

Promotion workflow

制品晋升流程

Pipeline Logs & Streaming

流水线日志与流式输出

Snapshot logs for a run

获取某次运行的日志快照

Real-time SSE streaming

实时SSE流式输出

Stream specific step

流式输出指定步骤的日志

Environment Deploy as Pipeline Alias

环境部署作为流水线别名

Basic usage

基础用法

Triggers the configured pipeline for test environment

触发测试环境的配置流水线

Pass inputs to the pipeline

向流水线传递输入参数

Bypass pipeline and do direct deploy

绕过流水线，执行直接部署

Promotion flow example

制品晋升流程示例

1. Build and deploy to test environment

1. 构建并部署到测试环境

2. Get release info from the test build

2. 从测试构建中获取发布信息

Output: rel_xxx

输出：rel_xxx

3. Promote to staging using the release_id

3. 使用release_id将制品晋升到预发布环境

Key behaviors

核心特性

Workflows

工作流

Workflow Hints

工作流提示

Conditional Steps

条件步骤

Step-Level Harness Overrides

步骤级Harness覆盖

Workflow env_overrides

工作流env_overrides

Per-Job Harness Override (Ad-Hoc Jobs)

单任务Harness覆盖（临时任务）

Or pass a full override object:

或传递完整的覆盖配置文件：

override.json: { "harness": "...", "model": "...", "reasoning_effort": "...", "variant": "...", "temperature": 0.2 }

override.json: { "harness": "...", "model": "...", "reasoning_effort": "...", "variant": "...", "temperature": 0.2 }

Slack Notifications, Retry, and File Refs

Slack通知、重试与文件引用

`build`
action

`build`
操作

Workflow
`env_overrides`

工作流
`env_overrides`