feat(surface): github.check_run and github.issue_comment triggers - #446
Conversation
Regenerated `packages/surface/src/triggers/github.ts` from the core GitHub mapping in AgentWorkforce/relayfile-adapters#279, which declares `check_run` and `issue_comment` as action-bearing webhook keys. The surface gains `github.check_run(action?)` and `github.issue_comment(action?)` — the two events a PR reviewer needs for merge-on-green and comment-driven directives — and `providerEventTypes.github` lists them, so `flows check` admits a subscription to either instead of refusing it as unpublished. Generated with the adapters checkout's `packages/core/mappings` alone, which is byte-for-byte what the published `@relayfile/adapter-core` tarball will carry, so `generate-triggers.mjs --check` reproduces these files once the SDK's pinned adapter-core is bumped to the release that contains #279. Until that bump the check refuses, by design. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (8)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe change adds GitHub ChangesGitHub event support
Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Feature Suggested reviewers: Merge Risk: ⚪ Minimal · up to The new GitHub event support is consistently parsed, serialized, exposed, and pinned; no merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. A rabbit hops where pull requests spring, Comment |
Review swarm: maintainabilityNo fresh transcript was produced for run |
Review swarm: historyNo fresh transcript was produced for run |
Review swarm: structureNo fresh transcript was produced for run |
Review swarm: FAILED
Cloud run: |
The GitHub source setting `events` (AgentWorkforce/cloud#3772) selects which records wake a listener: `issues` (default) or `pull_request`. The CLI validates it client-side like the other settings and the doc describes the pull-request run's input. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The release carrying relayfile-adapters#279 (`check_run` and `issue_comment` webhook keys). `generate-triggers.mjs` against the installed tarball reproduces the committed trigger modules byte for byte, and `--check` passes again. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
Devin Review found 1 potential issue.
1 flag not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)
| if (key === 'events' && !['issues', 'pull_request'].includes(setting.toLowerCase())) { | ||
| throw new CloudFlowError('invalid_input', `github events must be "issues" or "pull_request", got "${setting}".`); |
There was a problem hiding this comment.
🟡 Mixed-case event values reach Cloud
events=PULL_REQUEST passes parseTriggerSource, but the parser sends that original value. Cloud expects pull_request, so deployment cannot create the requested listener.
Learn more
The parser treats the event enum case-insensitively during validation but preserves the caller's spelling in settings. The deployment request later serializes settings without another normalization step.
Example: --on github:events=PULL_REQUEST passes validation because PULL_REQUEST.toLowerCase() is pull_request. The request still contains { events: "PULL_REQUEST" } instead of the Cloud enum { events: "pull_request" }.
Recommended fix: Either validate the original value against the exact enum or assign the normalized value to settings[key]. Add a test covering mixed-case input and the serialized deployment body.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Fixed in baa4f5e: the value is lowercased before it is stored in settings, so the deploy body carries pull_request whatever the shell typed; tests cover PULL_REQUEST and Pull_Request.
Validation was case-insensitive but the caller's spelling was serialized, so `events=PULL_REQUEST` passed the CLI and failed at Cloud (Devin). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…rovider trigger namespace Merges origin/main (#446) and moves the pin to 0.5.26, the first release that bundles every adapter's own mapping under mappings/adapters/ (relayfile-adapters#280). Triggers are regenerated from the installed tarball alone — no --adapters-dir — and `generate-triggers.mjs --check` passes: 47 providers, 502 events, PROVIDERS.md in sync. Conflicts resolved by taking main's cloud-deploy.* (untouched here) and this branch's superset github-events test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…bhooks (#456) * feat(surface): github.check_run and github.issue_comment triggers Regenerated `packages/surface/src/triggers/github.ts` from the core GitHub mapping in AgentWorkforce/relayfile-adapters#279, which declares `check_run` and `issue_comment` as action-bearing webhook keys. The surface gains `github.check_run(action?)` and `github.issue_comment(action?)` — the two events a PR reviewer needs for merge-on-green and comment-driven directives — and `providerEventTypes.github` lists them, so `flows check` admits a subscription to either instead of refusing it as unpublished. Generated with the adapters checkout's `packages/core/mappings` alone, which is byte-for-byte what the published `@relayfile/adapter-core` tarball will carry, so `generate-triggers.mjs --check` reproduces these files once the SDK's pinned adapter-core is bumped to the release that contains #279. Until that bump the check refuses, by design. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(sdk): flows deploy --on github:events=pull_request The GitHub source setting `events` (AgentWorkforce/cloud#3772) selects which records wake a listener: `issues` (default) or `pull_request`. The CLI validates it client-side like the other settings and the doc describes the pull-request run's input. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore(sdk): pin @relayfile/adapter-core 0.5.25 The release carrying relayfile-adapters#279 (`check_run` and `issue_comment` webhook keys). `generate-triggers.mjs` against the installed tarball reproduces the committed trigger modules byte for byte, and `--check` passes again. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(surface): trigger namespaces for every relayfile adapter with webhooks `scripts/generate-triggers.mjs` read only the mapping YAML that @relayfile/adapter-core bundles, and that was the two core fallbacks, so `flow().on(...)` could subscribe to Slack and GitHub and nothing else, although relayfile ingests events from 47 providers. The generator now applies three sources per provider: the core fallback mappings, each adapter's own mapping (`mappings/adapters/` in the package since relayfile-adapters#280, or `packages/<adapter>/` in a checkout) which supersedes the fallback as a whole, and the trigger catalog (`@relayfile/adapter-core/triggers`, fed by every adapter's `supportedEvents()`) for providers with no `webhooks:` block. Mapping-backed providers keep payload-aware signatures (`github.pull_request(action?)`); catalog-backed ones get `(filter?)`. Result: 47 namespaces, 502 events; `github` and `slack` are supersets of what #446 generated, so `--on github:events=` and the six fallback GitHub events are unchanged. Also: a reserved-namespace guard (`webhook`, `flow`, `schedule`, …), a generated `PROVIDERS.md` table covered by `--check`, and hyphenated ids mapped to identifiers (`azure_blob`, `google_drive`) with upstream spelling kept in the lowered filter. Merge condition: adapter-core published with relayfile-adapters#280 and the SDK pin bumped; until then `generate-triggers.mjs --check` (and its test) report github.ts/gitlab.ts/index.ts/PROVIDERS.md drift against 0.5.25 — 45 of the 47 providers already generate identically from the catalog it ships. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(surface): satisfy the strict test tsconfig in the all-providers trigger test Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(surface): union catalog events into mapping-backed providers Devin on #456: a provider with any `webhooks:` block lost every event the catalog listed but the mapping did not — gitlab kept 8 of the 53 it delivers, so ingress would refuse the other 45 and `flows check` had no namespace for them. The mapping describes payload shape for some events, never the delivered set; `supportedEvents()` does. Catalog events are now unioned into every provider with the plain `(filter?)` signature; a mapping-declared event keeps its signature. Where two upstream names mangle to one identifier (slack publishes both `reaction.added` and `reaction_added`) the mapping-declared event owns the method and the other remains in `providerEventTypes`, subscribable via `webhook(provider, { provider, type })` and listed in PROVIDERS.md. 47 providers, 570 events (was 502): gitlab 53, github 26, slack 21. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(surface): action-qualified events take a plain filter, never a second action Cursor on #456: `pull_request_edited(action?)` pinned the type to `pull_request.edited` and still accepted an action, a dual vocabulary that is easy to misuse. Only an aggregate event whose mapping extracts `action` takes one now (`pull_request`, `check_run`, `issue_comment`). Both spellings stay, because two ingresses deliver them: the aggregate form is what raw GitHub and the local receiver carry, the action-qualified form is what relayfile's Cloud ingress normalizes to; the README says which to use. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Relayflow Lead <lead@relayflows.local> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Summary
Regenerates the GitHub trigger surface with two events a PR-reviewer flow needs:
providerEventTypes.githubnow listscheck_runandissue_comment, soflows checkadmits those subscriptions (verified: a flow using all three ofcheck_run,issue_comment,pull_requestpasses preflight with this build and is refusedgithub.check_run is not a functionon main).Depends on
AgentWorkforce/relayfile-adapters#279 — adds the keys to the core mapping shipped in
@relayfile/adapter-core. The generated files here were produced from that branch'spackages/core/mappingsalone (exactly what the tarball carries), so after that lands and is released:@relayfile/adapter-coreinpackages/sdk/package.jsonto the release containing fix(cli): make help and single-step summaries readable #279node scripts/generate-triggers.mjs --check→Checked 2 provider trigger modulesUntil then
tests/generate-triggers.test.ts › reproduces all checked-in modules from the pinned adapter mappingsfails by construction — hence draft.Test plan
packages/surface: typecheck, build,tests/triggers-github-events.test.ts(new) +flow.test.tspackages/sdk: typecheck;provider-trigger-executor,provider-trigger-contract,check-triggerssuites green against a built kernelflows checkon a flow subscribing tocheck_run/issue_comment/pull_request→CHECK PASSEDgenerate-triggers.mjs --check— adapter-core pinned to 0.5.25 (ships fix(cli): make help and single-step summaries readable #279); regenerated from the installed tarball, byte-identical to the branch-generated files🤖 Generated with Claude Code
Summary by cubic
Adds
github.check_runandgithub.issue_commenttriggers for PR-reviewer flows, and alignsflows deploywith Cloud's GitHubeventssetting.providerEventTypes.githubnow listscheck_runandissue_comment, both accepting an optional action filter likegithub.pull_request.flows deploy --on github:events=...acceptsissuesorpull_request, lowercasing the value before it is sent soPULL_REQUESTno longer passes the CLI and then fails at Cloud;docs/CLOUD.mddescribes the pull-request run'sinput.pullRequest.@relayfile/adapter-coreto 0.5.25, which ships the upstream mappings, sogenerate-triggers.mjs --checkpasses.Written for commit baa4f5e. Summary will update on new commits.
Also in this PR
flows deploy … --on github:events=pull_request[,labels=…]— the CLI now accepts theeventssetting introduced by AgentWorkforce/cloud#3772 (validated toissues|pull_request), and docs/CLOUD.md describes the pull-request run'sinput.pullRequest. This part has no dependency on the adapter-core release.Note
Low Risk
SDK-side trigger parsing and generated surface additions; no changes to auth, credentials, or runtime execution paths beyond new allowed trigger types and deploy payload fields.
Overview
Adds
github.check_runandgithub.issue_commentto the generated GitHub trigger API (optional action filter, same pattern aspull_request), updatesproviderEventTypes.githubsoflows checkaccepts those subscriptions, and documents them in the triggers README. Regeneration is tied to@relayfile/adapter-core0.5.25.Separately,
flows deploy --on github:…now accepts aneventssetting (issuesorpull_request, normalized to lowercase inparseTriggerSource), with tests anddocs/CLOUD.mddescribing pull-request listener behavior andinput.pullRequeston runs.Reviewed by Cursor Bugbot for commit baa4f5e. Bugbot is set up for automated code reviews on this repo. Configure here.