Deploy multi-file Hub workflows (#3128)

* feat(hub): deploy canonical workflow bundles

Keep CLI deployment aligned with Hub's authored bundle boundary so validation and activation receive the same deterministic source files. Public documentation now teaches that boundary as the only configuration format.

* test(hub): assert validation diagnostics directly

* refactor(hub): deepen HTTP client module

* feat(hub): validate named agent configurations

* docs(hub): align Claude mode example
This commit is contained in:
Mohamed Boudra
2026-08-10 12:32:59 +02:00
committed by GitHub
parent b7f137c2a0
commit 05a0cabc07
49 changed files with 2475 additions and 3085 deletions
+32 -32
View File
@@ -1,6 +1,6 @@
---
title: GitHub triggers
description: Configure GitHub events as Hub triggers and route them into durable workflows.
description: Configure GitHub events with explicit step-scoped GitHub authority.
nav: GitHub
order: 67
category: Hub
@@ -8,46 +8,46 @@ category: Hub
# GitHub triggers
## Events
| `on` | Event |
| ------------------------------------ | ------------------------------------ |
| `github.issue_comment` | Comment on an issue or pull request. |
| `github.issues` | Issue event. |
| `github.pull_request_review` | Pull request review. |
| `github.pull_request_review_comment` | Diff comment. |
| `on` | Event |
| ------------------------------------ | -------------------------------------- |
| `github.issue_comment` | A comment on an issue or pull request. |
| `github.issues` | An issue. |
| `github.pull_request_review` | A pull request review. |
| `github.pull_request_review_comment` | A comment on a diff. |
GitHub sends every subscribed action. Each delivery that passes the filters starts a run.
Hub does not filter by webhook action. GitHub delivers a subscribed event for every action — created, edited, closed, deleted — and each delivery that passes the trigger's filters starts a run.
Which repositories produce events is set on the GitHub App installation. `filters.repo` narrows a trigger to one `owner/name` repository.
## Filters
`.paseo/workflows/github-change.yml`:
```yaml
name: github-change
on: github.issue_comment
max_runtime: 2h
filters:
repo: example/project
contains: "@paseo"
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
pull_requests: write
prompt:
- text: |
Implement the request and open a pull request with gh.
Call hub.finish_execution when done.
${{ paseo.prompt }}
```
`from_users` matches the sender's GitHub login. `contains` checks the event text; `pattern` checks its start. The text is the comment body for comments and reviews, and the issue title plus body for issues. All filters must pass.
`from_users` matches the GitHub login. `contains` checks event text and `pattern` checks its start. Comment events use the comment body; issue events use title plus body.
## Invocation
A GitHub trigger grants no token. Authority is the `github` block on the step that needs it. GitHub has no `hub.reply` capability; the agent acts through `gh` within the declared connection, repositories, and permissions.
Put the configured marker in the message, then put leading inputs in the text parsed after that marker:
```text
@paseo repo=project agent=claude investigate the failed sync
```
Hub consumes only declared consecutive headers and passes `investigate the failed sync` as `${{ paseo.prompt }}`. See [Hub workflows](/docs/hub/workflows) for input types, defaults, choices, and rejected Activity records.
## Credentials and replies
A GitHub trigger grants nothing by itself. A step that should comment, push, or open a pull request declares a [`github` block](/docs/hub/github); without one the agent has no token and no git configuration.
The event's identifiers are not part of the prompt. `${{ paseo.prompt }}` carries the comment body for comment events and the title plus body for issues, so give the agent work it can complete from that text alone — opening a pull request, for example — rather than replying to a thread it has no way to locate.
On comment events, Hub reacts on the triggering comment: 👀 when it accepts the event, 🚀 when the agent starts, 👍 when the step completes, and 👎 when it fails. Plain issue events get no reaction; watch those runs in Project → Activity.
`hub.reply` covers Slack and Discord, not GitHub. See [Tell the agent which tool to call](/docs/hub/workflows#tell-the-agent-which-tool-to-call).
On comment events, Hub reacts with 👀 when accepted, 🚀 when the agent starts, 👍 on completion, and 👎 on failure. `${{ paseo.prompt }}` contains normalized request text, not event identifiers. Use `${{ paseo.context }}` in prompt text when the step explicitly needs provider context.