Repository navigation
feat(deploy): surface daytona connect + gate in agentworkforce deploy - #232
Conversation
daytona's credential is captured out-of-band by the relay CLI (`agent-relay cloud connect daytona` → local `daytona login` → normalized token uploaded to the cloud credential-store), not the browser connect-session OAuth flow. Add a CLI_CAPTURED_PROVIDERS branch so the deploy walker, when daytona is not connected (interactive or --reconnect), instructs the capture command and gates the deploy instead of attempting a connect-session that 409s. already-connected / --no-prompt / --no-connect paths stay generic and identical to slack/github. Gating reads the existing /api/v1/workspaces/<ws>/integrations/daytona/status route (scope=deployer_user); connected requires oauth.connected:true / state:'ready' / ready:true, matching the cloud credential-store contract. Tests: 6 daytona tests (2 resolver-contract locking the connected/pending status shape, 4 walker behavior). Full deploy suite 193/193 green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe PR adds support for CLI-captured integration providers like Daytona that are authenticated through the relay CLI instead of OAuth. It defines ChangesCLI-captured provider support for Daytona
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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. Comment |
There was a problem hiding this comment.
Code Review
This pull request introduces support for CLI-captured integration providers (specifically Daytona) where credentials are captured out-of-band rather than via a browser OAuth flow. It adds helper functions and logic to detect these providers, instruct the user to run the appropriate CLI command, and gate the deployment. It also includes comprehensive tests for these scenarios. The reviewer suggested moving the isCliCapturedProvider check earlier in the connectIntegrations loop (before the noPrompt and noConnect checks) to ensure that users in non-interactive or CI/CD environments receive the specific CLI instruction rather than a generic non-interactive failure message.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| if (isCliCapturedProvider(provider)) { | ||
| // No browser OAuth flow exists for relay-CLI-captured providers — the | ||
| // credential is captured out-of-band. Don't show a misleading "(opens | ||
| // browser)" prompt or call connect-session (which 409s); instruct the | ||
| // user to run the capture command and gate the deploy. This covers both | ||
| // the interactive not-connected path and `--reconnect <provider>` (which | ||
| // reaches here when forceReconnect is set). | ||
| const command = `agent-relay cloud connect ${provider}`; | ||
| input.io.error( | ||
| `integrations.${provider}: not connected. Run \`${command}\` to capture the credential, then re-deploy.` | ||
| ); | ||
| outcomes.push({ | ||
| provider, | ||
| status: 'failed', | ||
| message: `not connected (run \`${command}\`)` | ||
| }); | ||
| continue; | ||
| } |
There was a problem hiding this comment.
The isCliCapturedProvider(provider) check is currently executed after the noPrompt and noConnect checks.\n\nWhen --no-prompt or --no-connect is passed (which is common in CI/CD or non-interactive environments), the deployment will fail with a generic and misleading error message (e.g., telling the user to run without --no-prompt to connect inline), rather than instructing them to run the specific CLI command (agent-relay cloud connect <provider>).\n\nSince CLI-captured providers cannot be connected via the browser anyway, we should check isCliCapturedProvider(provider) before the noPrompt and noConnect checks so that the user always gets the correct, actionable instruction.\n\n### Suggested Placement\nMove this block to be the very first check after the statusCheckFailure checks (around line 710, before if (input.noPrompt && !forceReconnect)).
Findings
Addressed comments
Advisory Notes
|
|
Implemented the validated review fix. Changed connect.ts so CLI-captured providers like Daytona are handled before the generic Updated connect.test.ts to assert the Daytona command under Addressed comments
Advisory Notes
Verification run locally with the CI workflow commands:
All passed locally. I am not printing |
|
Implemented the validated PR fix. Moved the CLI-captured provider branch ahead of generic Updated tests in connect.test.ts and connect.test.ts to cover Addressed comments
Advisory Notes
Local CI-equivalent commands run:
All passed locally. I’m not printing |
|
Implemented the validated fix in connect.ts: CLI-captured providers like Daytona are now handled before generic Updated tests in connect.test.ts and connect.test.ts to assert the relay CLI command for both non-interactive paths. Addressed comments
Advisory Notes
Verification passed locally:
I used a temporary |
|
Implemented the validated fix in connect.ts: CLI-captured providers like Daytona are now handled before generic Updated tests in connect.test.ts and connect.test.ts to assert the relay CLI command for both non-interactive paths. Addressed comments
Advisory Notes
Verification passed locally:
I used a temporary |
What
Surfaces the Daytona connect step in
agentworkforce deploy, mirroring how slack/github are gated — so a persona that declaresintegrations.daytona(e.g.daytona-monitor) can't deploy until the daytona credential exists in the cloud credential-store.Daytona's credential is captured out-of-band by the relay CLI (
agent-relay cloud connect daytona→ localdaytona login→ normalized token uploaded to the cloud credential-store), not the browserconnect-sessionOAuth flow other providers use. So the generic walker can't drive it inline (the cloud returns409 unknown_providerfor daytona's connect-session).Change
packages/deploy/src/connect.ts:CLI_CAPTURED_PROVIDERS = {daytona}+isCliCapturedProvider().--reconnect), instead of the misleading"(opens browser)"prompt + connect-session call, it errorsintegrations.daytona: not connected. Run \agent-relay cloud connect daytona` to capture the credential, then re-deploy.` and gates the deploy.already-connected/--no-prompt/--no-connectpaths stay generic and identical to slack/github.Gating keys on credential existence via the existing
GET /api/v1/workspaces/<ws>/integrations/daytona/status?scope=deployer_userroute — connected requiresconnectionMatched !== falseAND (oauth.connected:true|status/state:'ready'|ready:true), matching the cloud credential-store contract.Tests
packages/deploy/src/connect.test.ts— 6 daytona tests:relayfileIntegrationResolver.--no-promptgate, interactive instruct-and-gate,--reconnectinstruct-and-gate.Local verification: full deploy package suite 193/193 green,
tsc -pclean. This branch is a clean cherry-pick of the source commit ontomain, touching onlyconnect.ts/connect.test.ts(disjoint from main's other deploy changes).Context
Part of the daytona connect end-to-end effort (capture via relay CLI → cloud credential-store + status route + runtime env-injection → deploy gating here). Reviewable independently of the workforce catalog-refresh work.
🤖 Generated with Claude Code