freemo
565e7918a3
CI / typecheck (pull_request) Successful in 44s
CI / security (pull_request) Successful in 53s
CI / quality (pull_request) Successful in 32s
CI / lint (pull_request) Successful in 3m28s
CI / helm (pull_request) Successful in 23s
CI / build (pull_request) Successful in 54s
CI / unit_tests (pull_request) Failing after 6m21s
CI / docker (pull_request) Has been skipped
CI / e2e_tests (pull_request) Failing after 16m7s
CI / integration_tests (pull_request) Successful in 22m39s
CI / coverage (pull_request) Successful in 10m36s
CI / status-check (pull_request) Failing after 1s
CI / benchmark-publish (pull_request) Has been skipped
CI / benchmark-regression (pull_request) Successful in 56m9s
Implemented an explicit --container-id option as an alternative to --image for container-instance resources and added comprehensive validation, data storage, and fast-path container resolution. - Added --container-id option to resource_add() in src/cleveragents/cli/commands/resource.py as an alternative to --image for container-instance resources - Enforced mutual exclusion: --container-id and --image are mutually exclusive; container-instance requires one or the other - Restricted --container-id to container-instance only (not devcontainer-instance) - Persisted container_id in resource properties when provided - Updated DevcontainerHandler._find_running_container() in src/cleveragents/resource/handlers/devcontainer.py to use the stored container_id as a fast path before falling back to docker label search - Added container_id to container-instance cli_args in src/cleveragents/application/services/_resource_registry_data.py - Created features/container_id_flag.feature and features/steps/container_id_flag_steps.py with 5 unit test scenarios - Created features/container_id_integration.feature and features/steps/container_id_integration_steps.py with 5 integration test scenarios Key design decisions: - Used isinstance(stored_id, str) guard in handler for Pyright type narrowing - Validation raises typer.Abort() for clean CLI error handling - No behavioral changes for devcontainer-instance resources ISSUES CLOSED: #2598
37 lines
1.9 KiB
Gherkin
37 lines
1.9 KiB
Gherkin
@container-id-integration
|
|
Feature: container-instance --container-id integration
|
|
Verifies the full end-to-end flow for attaching a container-instance
|
|
resource to an existing container via the --container-id flag.
|
|
|
|
Scenario: CLI add container-instance with --container-id succeeds
|
|
Given a fresh in-memory resource registry for container_id
|
|
And built-in types are bootstrapped for container_id
|
|
When I run resource add container-instance with container-id "abc123def456"
|
|
Then the container_id command should succeed
|
|
And the container_id output should contain "Added resource"
|
|
|
|
Scenario: container_id is persisted in resource properties
|
|
Given a fresh in-memory resource registry for container_id
|
|
And built-in types are bootstrapped for container_id
|
|
When I run resource add container-instance with container-id "abc123def456"
|
|
And I show the container_id resource "local/test-ctr"
|
|
Then the container_id show output should contain "abc123def456"
|
|
|
|
Scenario: CLI rejects --container-id and --image together
|
|
Given a fresh in-memory resource registry for container_id
|
|
And built-in types are bootstrapped for container_id
|
|
When I run resource add container-instance with both container-id and image
|
|
Then the container_id command should fail
|
|
|
|
Scenario: CLI rejects container-instance with neither --image nor --container-id
|
|
Given a fresh in-memory resource registry for container_id
|
|
And built-in types are bootstrapped for container_id
|
|
When I run resource add container-instance with no image or container-id
|
|
Then the container_id command should fail
|
|
|
|
Scenario: Handler returns stored container_id without docker subprocess
|
|
Given a container-instance resource with stored container_id "deadbeef1234"
|
|
When I call _find_running_container on the resource
|
|
Then the container_id find result should be "deadbeef1234"
|
|
And no docker subprocess should have been called
|