Problem
Sessions that run in a hosted environment receive a fixed allocation of CPU, memory, and disk. That allocation is not visible before the session starts and is not configurable. For a large repository, the first indication that capacity is insufficient is a failure partway through dependency installation, a build, or a test run — after the setup time has already been spent.
Large repositories, native application builds, and multi-platform validation all need substantially more capacity than a small allocation provides. There is also no documented pattern for delegating validation that the hosted environment cannot perform to external CI and consuming the result.
What is missing
- Effective CPU, memory, disk, operating system, and timeout values are not reported to the caller.
- There is no way to select a larger or differently configured environment where one is available.
- Caching behavior across sessions is undocumented.
- There is no documented pattern for delegating unsupported platform validation to external CI.
Proposed behavior
- The session reports its effective environment — operating system, CPU count, memory, available disk, timeout, and cache configuration — before work begins.
- Repository or organization owners can select from approved environment profiles.
- Documented guidance exists for delegating validation that cannot run in the hosted environment to external CI, and for the session to consume those results.
- Capacity-related failures are identified as such, rather than surfacing as generic build or test errors.
Example scenario
A caller starts a session against a large repository. The session reports its capacity up front, so the caller knows immediately whether a full build is viable or whether validation should be delegated to external CI.
Acceptance criteria
- Effective environment capacity is programmatically discoverable.
- At least one mechanism exists to request a larger environment where supported.
- Capacity exhaustion produces a distinct, documented error.
Related
Problem
Sessions that run in a hosted environment receive a fixed allocation of CPU, memory, and disk. That allocation is not visible before the session starts and is not configurable. For a large repository, the first indication that capacity is insufficient is a failure partway through dependency installation, a build, or a test run — after the setup time has already been spent.
Large repositories, native application builds, and multi-platform validation all need substantially more capacity than a small allocation provides. There is also no documented pattern for delegating validation that the hosted environment cannot perform to external CI and consuming the result.
What is missing
Proposed behavior
Example scenario
A caller starts a session against a large repository. The session reports its capacity up front, so the caller knows immediately whether a full build is viable or whether validation should be delegated to external CI.
Acceptance criteria
Related