docs(contributing): document testing agent changes against a remote provider - #832
docs(contributing): document testing agent changes against a remote provider#832skevetter wants to merge 1 commit into
Conversation
…rovider Testing changes to pkg/agent/pkg/git against a local docker provider just works, since the CLI process is the agent. Against a remote/SSH provider, the agent is a separate binary injected onto that host, and two things bit us debugging the git-lfs install fix: dev builds skip the remote version check (so a stale cached binary silently gets reused instead of a freshly built one), and DEVSY_AGENT_BINARY has to match the remote's OS/arch, not the local machine's. Adds a cli:test:remote task that builds dev binaries for every OS/arch, clears the remote's cached agent binary, and runs `up --reset` with DEVSY_AGENT_BINARY pointed at the right one.
✅ Deploy Preview for images-devsy-sh canceled.
|
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
✅ Deploy Preview for devsydev canceled.
|
Up to standards ✅🟢 Issues
|
1 participant
Summary
dockerprovider case, where the CLI process itself is the agent. For remote/SSH/cloud providers, the agent runs as a separate binary injected onto that host — testing a change there hit two real gotchas while validating fix(git): check write/root capability before installing git-lfs #831 against a livews3-sshworkspace:version == v0.0.0) skip the remote version check and only verify a binary exists at the target path, so a stale cached agent binary is silently reused instead of a freshly built one.DEVSY_AGENT_BINARYmust match the remote host's OS/arch, not the local machine's — a plaingo build .on a macOS laptop injected onto a Linux ARM64 host fails withposix_spawn: no such file or directory.CONTRIBUTING.mdexplaining both gotchas and the manual steps.task cli:test:remote(Taskfile.yml) to automate it: builds dev binaries for every OS/arch via the existingcli:build:dev, clears the remote's cached binary via SSH, and runsworkspace up --resetwithDEVSY_AGENT_BINARYpointed at the binary matching the remote's OS/arch.task cli:test:remoteend-to-end against a realws3-sshworkspace (HOST=ws3@orb AGENT_PATH=/tmp/skevetter/devsy/agent task cli:test:remote -- <workspace>) — builds, force-reinjects, and brings the workspace up successfully.