Repository navigation
feat(envs): accept and forward the universe artifact - #123
Open
mandykwok-scale wants to merge 3 commits into
Open
mandykwok-scale wants to merge 3 commits into
mandykwok-scale wants to merge 3 commits into
Conversation
Companion to the `deploy_env` change that carries `artifact_id` / `artifact_version`: nothing received them, because no env declares them and `deploy_env` only passes a kwarg the env's signature accepts. The three built-in envs that define `deploy()` now take both and hand them to `deploy_through_provider`, which already splats options onto the provider. Both default to None, so every existing caller is unchanged. The built-in providers declare them too, and ignore them. They have to: `deploy_through_provider` splats every option onto `provider.deploy()`, and neither built-in takes `**kwargs`, so an undeclared option is a TypeError on the real deploy path. `test_every_option_the_env_maps_is_one_a_declared_provider_takes` exists to catch exactly that, and did. Two existing tests pinned the provider's option set exactly; both now expect the two new keys. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The test covered MultiEnv only. All three built-in envs carry the artifact the same way, so a value dropped in one of the other two would not have failed anything. Parametrised over MultiEnv, MCPServerEnv and WebsiteEnv, each asserting both the supplied values and the absent case. The MCPServerEnv case names the plugin provider explicitly: left on the default gateway it takes the real provider path and fails on state config, unrelated to what is being checked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
earakely-scale
approved these changes
Oct 9, 2026
This branch has not been deployed
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.
Motivation
Companion to #122, which adds
artifact_id/artifact_versiontodeploy_envso a provider can tell which universe a run will load — the pool key a warm environment pool needs.On its own #122 does nothing:
deploy_envonly passes a kwarg the env's signature accepts, and no env declares these. This closes that.Change
The three built-in envs that define
deploy()—MultiEnv,MCPServerEnv,WebsiteEnv— take both params and hand them todeploy_through_provider, which already splats options onto the provider. Both default toNone, so every existing caller is unchanged.The built-in providers declare them too, and ignore them. That is not cosmetic.
deploy_through_providercallsprovider.deploy(env, sandbox_provider, **options), and neither built-in provider takes**kwargs— so an option an env maps but no provider declares is aTypeErroron the real deploy path.test_every_option_the_env_maps_is_one_a_declared_provider_takesguards exactly this, and caught it here before it shipped. Worth knowing if you add options in future: the plugin-provider tests pass either way, because their stubs do take**options.Test plan
Nonefor both when the caller names nonetest_multi_env_plugin_providerandtest_mcp_server_plugin_providereach pinned the provider's option set exactly, and now expect the two new keystst/unit/env/envs: 259 passed, 2 failed — both failures (test_put_stores_the_env_provider_type_it_is_given,test_put_defaults_to_the_gateway) reproduce on a clean tree in this venv and are unrelatedScope
Still no behaviour change. Together with #122 the universe reaches the provider; a provider that keys on it comes next.
🤖 Generated with Claude Code

Confidence Score: 5/5
The PR appears safe to merge.Summary
Built-in environment deploys now pass an optional universe artifact ID and version to providers, so providers can identify which universe a run will load. Both values default to
None, and the built-in providers accept them without changing how they launch environments.Diagram
%%{init: {'theme': 'neutral'}}%% flowchart LR A["Deploy request"] --> B["MultiEnv / MCPServerEnv / WebsiteEnv"] B --> C["Provider deployment"] C --> D["Built-in provider accepts artifact details"]Reviews (3) · Last reviewed commit: "style(providers): drop the comments on t..." · Reviewed by Greptile