winterbaume-codebuild

CodeBuild service implementation for winterbaume.

This crate is part of the winterbaume workspace — a suite of in-process AWS service mocks for Rust. Use the umbrella winterbaume crate to pull in all services at once, or depend on this crate directly for CodeBuild only.

Winterbäume is not affiliated with, endorsed by, or sponsored by Amazon Web Services, Inc. or Amazon.com, Inc. Amazon Web Services, AWS, and related marks are trademarks of Amazon.com, Inc. or its affiliates. All other trademarks are the property of their respective owners.

Coverage

Metric	Value
Service	CodeBuild
AWS model	`codebuild`
Protocol	awsJson1.1
winterbaume coverage	29/59 operations (49.2%)
stubs (routed, returns empty/default)	0/59 operations (0.0%)
moto coverage	9/59 operations (15.3%)
floci coverage	0/59 operations (0.0%)
kumo coverage	0/59 operations (0.0%)
Coverage report date	2026-05-06

Coverage is generated from .agents/docs/API_COVERAGE.md by update_readme.py. The winterbaume row counts only operations with real, state-backed logic; stubs counts handlers that route the request and return an empty/default response without real behaviour. Operation-count coverage is a prioritisation signal, not a behavioural guarantee.

See the workspace README.md for setup, usage, and the full cross-service coverage table.

Server-mode usage

Start winterbaume-server and point the AWS CLI at it:

cargo run -p winterbaume-server -- --host 127.0.0.1 --port 5555

export AWS_ENDPOINT_URL=http://localhost:5555
aws codebuild list-projects

Current Network Resource Stub Semantics

CodeBuild currently has generated and snapshot fields for VPC configuration, but the implemented state does not create network resources.

Project snapshots expose a vpc_config JSON slot, and current snapshot construction sets it to None.
Builds and projects do not allocate ENIs, attach to subnets, or track security group membership.
Networking-related Smithy fields are therefore effectively ignored by the implemented service state unless a future handler explicitly stores them.
The implementation does not consult winterbaume-ec2 state for these identifiers, so it does not check that referenced VPCs, subnets, security groups, VPC endpoints, network interfaces, or load balancers exist, belong to the same VPC, or are in a usable lifecycle state.

Example

use aws_sdk_codebuild::config::BehaviorVersion;
use winterbaume_codebuild::CodeBuildService;
use winterbaume_core::MockAws;

#[tokio::main]
async fn main() {
    let mock = MockAws::builder()
        .with_service(CodeBuildService::new())
        .build();

    let config = aws_config::defaults(BehaviorVersion::latest())
        .http_client(mock.http_client())
        .credentials_provider(mock.credentials_provider())
        .region(aws_sdk_codebuild::config::Region::new("us-east-1"))
        .load()
        .await;

    let client = aws_sdk_codebuild::Client::new(&config);

    let resp = client
        .list_projects()
        .send()
        .await
        .expect("list_projects should succeed");
    println!("Projects: {}", resp.projects().len());
}

Implemented APIs (29)

BatchDeleteBuilds
BatchGetBuilds
BatchGetProjects
BatchGetReportGroups
CreateProject
CreateReportGroup
CreateWebhook
DeleteProject
DeleteReportGroup
DeleteResourcePolicy
DeleteSourceCredentials
DeleteWebhook
DescribeTestCases
GetResourcePolicy
ImportSourceCredentials
InvalidateProjectCache
ListBuilds
ListBuildsForProject
ListProjects
ListReportGroups
ListReportsForReportGroup
ListSourceCredentials
PutResourcePolicy
RetryBuild
StartBuild
StopBuild
UpdateProject
UpdateReportGroup
UpdateWebhook