* feat(website): serve paseo.sh in Simplified Chinese
Every page of the website now has a Simplified Chinese version under
/zh-CN: the interface, docs, blog posts, comparison pages, legal pages,
all changelog releases and the homepage mockup. English URLs are unchanged.
The URL alone decides the language. There is no browser-language redirect
and no stored preference, because either would have to redirect the
unprefixed English URLs that people share and search engines index.
Internal links carry the page's language instead, and hreflang alternates
point Chinese search results at /zh-CN.
Translated headings pin the English anchor with {#id}, so section links
work in both languages. content-translations.test.ts fails when a page
has no translation or a translation's headings drift from the English.
Changelog releases and plugin listings without a translation render
whole in English under a notice, so a release never waits on one.
Plugin manifests and the registry gain optional translations and
OVERVIEW.zh-CN.md fields; older clients and registries ignore them.
* feat(website): replace the native language select with an EN/ZH menu
The header showed an OS-native select whose popup did not match the site.
The trigger now shows the language abbreviated (EN, ZH) and opens a menu in
the app's dropdown style that names each language in itself, with its name
in the page language underneath. Rows are real links to the same page in
that language; arrows, Escape, outside presses and taps behave as a menu
button, and the menu keeps itself on screen when a narrow header pushes the
trigger toward an edge.
Also drops the stray space after the full-width comma in the Chinese
homepage subtitle.
* docs(website): translate main's new docs and 0.12.0 release notes
Main added Keep run workspaces to the schedules docs, rewrote plugin icons
around inline SVG, and promoted 0.12.0 with new entries. Bring the Chinese
pages and changelog in line so no section falls back to English.
* fix(server): leave plugin listing translations to the registry
The daemon rejected manifests whose translations the registry would refuse,
so a plugin main installs could fail to load here. Paseo never reads
translations; the registry validates them at publish. Docs now say which
checks are automated at publish and which are human review.
* docs(plugins): describe the registry's final overview translation discovery
* style(server): format manifest test
* test(app): measure sidebar rows one at a time
After a reload the developer error toast appears while expectVerticalOrder
measures every row at once. Each concurrent boundingBox runs the toast
locator handler, and only one of them resumes, so the poll timed out on
every attempt since #7424. Measuring sequentially keeps one action in flight.
* test(app): return sidebar row measuring to main
#7480 hides the developer toast instead of running a locator handler, so
measuring the rows concurrently no longer races it. Reverts 41ac23016.
* test(app): wait for the compact shell before opening compact Changes
The shell survives the breakpoint, so right after the resize the wide
Explorer could still be visible: the test skipped the Explorer toggle and
the tab then disappeared, or toggled at the wrong time. Wait for the
compact-shell marker, as the composer helpers do since #7424.
* docs(website): translate main's plugin file panel docs
* test(app): edit the code font size after the font family remount
A committed appearance change remounts the settings screen through
AppearanceStyleBoundary, and the new form starts from the stored size.
Filling the size before that remount lost the edit in CI.
* docs(website): translate main's client/ui import docs
Follows #7474: one /client/ui entry, StreamedText instead of useRevealedText,
SettingsGroup dropped from the settings table, and the new
'UI imports in v0.13' migration section.
* test(app): wait for the previous layout's file panel picker to leave
After a resize the old layout's picker animates out while the new one is
already mounted, so the Use button matched two elements and the strict
locator failed. Wait for the shell's layout and a single picker first.
7.2 KiB
title, description, nav
| title | description | nav |
|---|---|---|
| GitHub 触发器 | 由特定的 GitHub issue、PR、评论和标签启动 Hub workflow。 | GitHub |
GitHub 触发器
使用语义化的 GitHub 事件,由某一个 GitHub 操作启动 workflow。把下面的 workflow 添加到一个仓库中(该仓库的 .paseo/hub.yml 定义了 dev 环境和 codex Agent),然后激活配置包。
分拣新 issue
.paseo/workflows/triage-issue.yml:
name: triage-issue
on: github.issue_created
max_runtime: 2h
filters:
repo: example/project
from_users: [maintainer]
steps:
- id: triage
environment: dev
max_runtime: 30m
idle_timeout: 5m
agent: codex
github:
connection: example-github
repositories: [example/project]
permissions:
issues: write
prompt:
- text: |
Triage the new issue. Add the appropriate labels and leave a short comment
explaining the result with gh. Use this event context:
${{ paseo.context }}
Call hub.finish_execution when done.
github.issue_created 只在有人创建 issue 时触发。from_users 是必填的,匹配引发该事件的 GitHub 登录名。
审查新的 PR
.paseo/workflows/review-pull-request.yml:
name: review-pull-request
on: github.pull_request_created
max_runtime: 2h
filters:
repo: example/project
from_users: [maintainer]
steps:
- id: review
environment: dev
max_runtime: 90m
idle_timeout: 10m
agent: codex
github:
connection: example-github
repositories: [example/project]
permissions:
contents: read
pull_requests: write
prompt:
- text: |
Review the new pull request and submit your findings with gh. Use this event context:
${{ paseo.context }}
Call hub.finish_execution when done.
github.pull_request_created 只在有人创建 PR 时触发。
回复新评论
.paseo/workflows/respond-to-issue-comment.yml:
name: respond-to-issue-comment
on: github.issue_comment_created
max_runtime: 2h
filters:
repo: example/project
contains: "@paseo"
from_users: [maintainer]
steps:
- id: respond
environment: dev
max_runtime: 30m
idle_timeout: 5m
agent: codex
github:
connection: example-github
repositories: [example/project]
permissions:
issues: write
prompt:
- text: |
Respond to the new issue comment with gh. Address this request:
${{ paseo.prompt }}
Use this event context:
${{ paseo.context }}
Call hub.finish_execution when done.
.paseo/workflows/respond-to-pull-request-comment.yml:
name: respond-to-pull-request-comment
on: github.pull_request_comment_created
max_runtime: 2h
filters:
repo: example/project
contains: "@paseo"
from_users: [maintainer]
steps:
- id: respond
environment: dev
max_runtime: 30m
idle_timeout: 5m
agent: codex
github:
connection: example-github
repositories: [example/project]
permissions:
pull_requests: write
prompt:
- text: |
Respond to the new pull-request conversation comment with gh. Address this request:
${{ paseo.prompt }}
Use this event context:
${{ paseo.context }}
Call hub.finish_execution when done.
issue 讨论使用 github.issue_comment_created,PR 对话使用 github.pull_request_comment_created。针对某一行改动的评论属于 diff 评论,由旧的 github.pull_request_review_comment 事件处理。
对于 github.issue_comment_created、github.pull_request_comment_created、github.issue_comment 和 github.pull_request_review_comment,Hub 接受投递时会回应 👀,Agent 启动时回应 🚀,完成时回应 👍,失败时回应 👎。
issue 就绪时开始工作
.paseo/workflows/implement-ready-issue.yml:
name: implement-ready-issue
on: github.issue_label_added
max_runtime: 2h
filters:
repo: example/project
label: ready-for-agent
from_users: [maintainer]
steps:
- id: implement
environment: dev
max_runtime: 90m
idle_timeout: 10m
agent: codex
github:
connection: example-github
repositories: [example/project]
permissions:
contents: write
issues: write
pull_requests: write
prompt:
- text: |
Implement the issue that was marked ready for an agent. Create a branch,
push it, and open a pull request with gh. Use this event context:
${{ paseo.context }}
Call hub.finish_execution when done.
label 匹配此次事件添加的标签。匹配不区分大小写,因此 ready-for-agent 也能匹配 Ready-For-Agent。
选择事件
on |
触发时机 |
|---|---|
github.issue_created |
创建 issue。 |
github.pull_request_created |
创建 PR。 |
github.issue_comment_created |
在 issue 上创建评论。 |
github.pull_request_comment_created |
在 PR 上创建对话评论。 |
github.issue_label_added |
为 issue 添加标签。 |
github.pull_request_label_added |
为 PR 添加标签。 |
issue 上的评论选择 github.issue_comment_created,PR 上的对话评论选择 github.pull_request_comment_created。GitHub 把两者都作为 issue 评论投递;Hub 会替你区分它们。针对某一行改动的评论属于 diff 评论,由旧的 github.pull_request_review_comment 事件处理。
过滤 GitHub 事件
每个来源于外部的 workflow 都需要一个非空的 from_users 允许列表。GitHub 过滤器以 AND 方式组合:仓库、连接、发送者、内容、变化的标签以及要求当前具有的标签都必须匹配。
对于 issue 和 PR 事件,contains 和 pattern 检查标题加正文。对于评论事件,它们检查评论正文。contains 是子串匹配;pattern 匹配开头。
当被添加的标签本身很重要时,请在 github.issue_label_added 或 github.pull_request_label_added 中使用 label。当条目必须当前具有列出的每一个标签时,请使用 labels。两者比较标签时都不区分大小写。例如,labels: [bug, backend] 要求同时具有这两个标签,而不是其中任意一个。
配置参考列出了所有 GitHub 事件和过滤器。
旧事件兼容
现有的 workflow 使用 github.issues、github.issue_comment、github.pull_request_review、github.pull_request_review_comment 和 github.push 时行为保持不变。新的 workflow 请优先使用上面的语义化事件。语义化 workflow 和旧 workflow 可能同时匹配同一次投递,因此会各自启动一次运行。
GitHub 触发器不授予任何 token。权限来自需要它的 step 上的 github 块。GitHub 没有 hub.reply 能力;Agent 在声明的连接、仓库和权限范围内通过 gh 执行操作。