Repository navigation
feat(tools): distro-aware tool commands - #205
Merged
Kavya Sree Kaitepalli (KavyaSree2610) merged 2 commits intoOct 29, 2026
Merged
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #205 +/- ##
==========================================
+ Coverage 76.48% 77.03% +0.55%
==========================================
Files 46 47 +1
Lines 3113 3192 +79
==========================================
+ Hits 2381 2459 +78
- Misses 732 733 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
Tool YAML *_commands fields (install/verify/setup/uninstall) now accept either a list (generic: runs on every distro) or a map keyed by distro ID from /etc/os-release and/or "generic". The distro is always read from the running sandbox, never configured: - Known distro: its ID wins, then its ID_LIKE entries (so "debian" covers Ubuntu), then "generic"; with no match the tool fails with UnsupportedDistroError before running anything. - Unknown distro (no /etc/os-release): "generic", else the first entry, is run with a warning; a failing command is the last resort. - Environment.get_distro_ids() reads and caches /etc/os-release. - ToolAbstract.resolve_commands() selects commands; map keys are validated and normalised to lower case. - Internal tools resolve against the sandbox, external tools against the host (microbots.utils.os_release). - cscope, browser-use and the tesseract docs example use apt-get, so their commands are now keyed to "debian". - Document the format in the custom tool walkthrough. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Bala (0xba1a)
force-pushed
the
bala/distro-aware-tools
branch
from
October 28, 2026 08:54
a409f03 to
129e301
Compare
…ribute Review follow-ups: - resolve_commands() takes the distro IDs as a list instead of a callable. Internal tools gather them with env.get_distro_ids() and external tools with host_distro_ids() before resolving. - Environment declares the _distro_ids cache as a class attribute (None until /etc/os-release is read), replacing the getattr fallback. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Kavya Sree Kaitepalli (KavyaSree2610)
approved these changes
Oct 29, 2026
Kavya Sree Kaitepalli (KavyaSree2610)
left a comment
Collaborator
There was a problem hiding this comment.
LGTM
This was referenced Oct 29, 2026
Bala (0xba1a)
added a commit
that referenced
this pull request
Nov 2, 2026
Review follow-up: CopilotBot had its own per-distro Node.js/copilot-cli install table and matching logic, duplicating the distro-aware tool command resolution (#205). Move it into the normal tool model: - New tool_definitions/copilot-cli.yaml: Node.js 22 per distro (NodeSource on Debian; checksum-verified nodejs.org build on Azure Linux, which only packages Node 20) and the pinned @github/copilot@1.0.39 CLI, verified with `copilot --version`. It has no usage instructions, since it is infrastructure rather than a tool for the model. - CopilotBot._install_copilot_cli() installs and verifies that tool; _NODE_INSTALL_COMMANDS, _COPILOT_CLI_PACKAGE and _node_install_commands are removed. Unsupported distros now raise UnsupportedDistroError, and an undetectable distro falls back to the first (Debian) entry. - The headless server start, token injection and readiness check stay in CopilotBot; the host-side SDK stays the `ghcp` pip extra. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Bala (0xba1a)
added a commit
that referenced
this pull request
Nov 2, 2026
Review follow-up: CopilotBot had its own per-distro Node.js/copilot-cli install table and matching logic, duplicating the distro-aware tool command resolution (#205). Move it into the normal tool model: - New tool_definitions/copilot-cli.yaml: Node.js 22 per distro (NodeSource on Debian; checksum-verified nodejs.org build on Azure Linux, which only packages Node 20) and the pinned @github/copilot@1.0.39 CLI, verified with `copilot --version`. It has no usage instructions, since it is infrastructure rather than a tool for the model. - CopilotBot._install_copilot_cli() installs and verifies that tool; _NODE_INSTALL_COMMANDS, _COPILOT_CLI_PACKAGE and _node_install_commands are removed. Unsupported distros now raise UnsupportedDistroError, and an undetectable distro falls back to the first (Debian) entry. - The headless server start, token injection and readiness check stay in CopilotBot; the host-side SDK stays the `ghcp` pip extra. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Kavya Sree Kaitepalli (KavyaSree2610)
pushed a commit
that referenced
this pull request
Nov 2, 2026
#210) * feat(copilot): SDK session options, skill tracking and image selection Let CopilotBot use a repository's agent skills and run on any sandbox image: - session_options: extra kwargs forwarded to CopilotClient.create_session (skill_directories, custom_agents, mcp_servers, working_directory, ...). Keys are validated against the installed SDK; model, provider, streaming, hooks and system_message stay managed by CopilotBot. run() accepts per-run overrides. Only option names are logged. - invoked_skills: names of skills used in the last run (skill.invoked events); skill load/invoke events are logged. - image: container image of the auto-created environment. copilot-cli's Node.js 22 is installed for the distro read from /etc/os-release (NodeSource on Debian, checksum-verified nodejs.org build on Azure Linux, which only packages Node 20; Debian's steps when the distro is unknown; unsupported distros fail before running). - Integration test: the agent upgrades util-linux in an Azure Linux checkout using its AGENTS.md and azldev-* skills (READ_ONLY by default, AZURELINUX_KEEP_CHANGES=1 to keep the changes). - Docs: session options and Azure Linux skills example. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> # Conflicts: # docs/advanced/bots/copilot-bot.md # src/microbots/bot/CopilotBot.py # test/bot/test_copilot_bot.py * refactor(copilot): install copilot-cli from a tool definition Review follow-up: CopilotBot had its own per-distro Node.js/copilot-cli install table and matching logic, duplicating the distro-aware tool command resolution (#205). Move it into the normal tool model: - New tool_definitions/copilot-cli.yaml: Node.js 22 per distro (NodeSource on Debian; checksum-verified nodejs.org build on Azure Linux, which only packages Node 20) and the pinned @github/copilot@1.0.39 CLI, verified with `copilot --version`. It has no usage instructions, since it is infrastructure rather than a tool for the model. - CopilotBot._install_copilot_cli() installs and verifies that tool; _NODE_INSTALL_COMMANDS, _COPILOT_CLI_PACKAGE and _node_install_commands are removed. Unsupported distros now raise UnsupportedDistroError, and an undetectable distro falls back to the first (Debian) entry. - The headless server start, token injection and readiness check stay in CopilotBot; the host-side SDK stays the `ghcp` pip extra. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * build(copilot): upgrade github-copilot-sdk to 1.0.28 and copilot-cli to 1.0.105 github-copilot-sdk 1.x pins the copilot-cli release it targets (CLI_VERSION in copilot/_cli_version.py); 1.0.28 targets 1.0.105. The 0.3.0 / 1.0.39 pair is incompatible with either newer half (0.3.0 cannot parse 1.0.105 responses; 1.0.39 lacks the 1.x `connect` RPC). - Connect with CopilotClient(connection=UriRuntimeConnection(...)), which replaces ExternalServerConfig. - Import PermissionHandler from copilot.session only and SessionEventType from the public copilot.session_events module; a pre-1.x SDK now fails with an explicit upgrade message. - Cross-reference the two pins in pyproject.toml and copilot-cli.yaml, let the ghcp CI job install the `ghcp` extra instead of repeating the pin, and add test_copilot_version_pins.py to check the pins (and, under `ghcp`, that the installed SDK targets the pinned CLI). - Replace the pre-0.3.0 SDK-layout tests with 1.x import/connection tests. - Make the session-options test independent of COPILOT_BYOK_MODEL. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * feat(copilot): add model_id for BYOK deployments with custom names copilot-cli 1.0.105 picks request settings (temperature, reasoning_effort, prompts, token limits) from the model name. For a BYOK deployment with a custom name, such as CI's Azure `mini-swe-agent-gpt5`, it falls back to generic defaults and sends temperature 0, which GPT-5 rejects. - New `model_id` parameter and COPILOT_BYOK_MODEL_ID env var, mapped to the SDK's provider `model_id`; the deployment name is kept as `wire_model`. - ghcp CI job: use the Responses wire API and COPILOT_BYOK_MODEL_ID=gpt-5. - Docs and unit tests for the new option. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Tool YAML command fields (
install_commands,verify_commands,setup_commands,uninstall_commands) can now be distro-specific. Microbots picks the right commands from the sandbox's/etc/os-release, so the same tool definition can support several sandbox images. The sandbox's distribution is never configured separately.This is the second PR in the stack, following #202 (stock MCR images prepared on the fly).
Format
Each
*_commandsfield accepts either form:/etc/os-release(for exampledebianorazurelinux) and/orgeneric.Resolution
For a map, Microbots reads the sandbox's
/etc/os-release:IDwins, then itsID_LIKEentries (sodebianalso covers Ubuntu), thengeneric.UnsupportedDistroErrorbefore any command runs, and the error says which entry to add.generic, or the first entry if there's nogeneric. A failing command is the last resort.Changes
Environment.get_distro_ids()reads and caches the sandbox's/etc/os-release(ID, thenID_LIKE).ToolAbstract.resolve_commands()selects the commands. Map keys are validated (no empty or duplicate keys) and lower-cased./etc/os-release(newmicrobots.utils.os_release).cscope,browser-useand the tesseract docs example useapt-get, so their commands are now keyed todebian. Their behaviour on the default Debian image is unchanged.Testing
test/tools/test_distro_commands.pycovers resolution order, the unknown-distro fallback, theUnsupportedDistroErrormessage, key validation, os-release parsing and caching, and internal/external tool wiring. Unit tests: 705 passed. The 6 failures intest_microbot.py::TestMicrobotUnitand 4 errors intest_memory_tool_integration.pyalso occur onmainand come from my local environment.mcr.microsoft.com/devcontainers/python:3.11: detected['debian'], andcscope.yamlinstalled and verified./etc/os-releaseremoved: the tool fell back to its first entry with a warning.mcr.microsoft.com/azurelinux/base/core:3.0: detected['azurelinux'], andcscope.yamlwas rejected withUnsupportedDistroErrorbefore running anything.Upcoming PRs in this stack
AZURELINUX_IMAGE), with animageoption on the bots.root_accessfor the sandbox shell.rpm/mock/azldevtool definitions.session_optionsand skill tracking, so it can use a repository's agent skills.