Story (Required)

This feature introduces a `stepResources` field in the Build and BuildRun APIs, enabling developers to override CPU, memory, or ephemeral storage requirements for specific steps defined in a BuildStrategy or ClusterBuildStrategy, without needing to duplicate and modify the strategy itself.

Background (Required)

Currently, resource requirements are hardcoded at the strategy level, for which either we need to duplicate strategies for different resource needs or request platform admins to modify shared strategies.

With this change, users can specify per-step resource overrides directly in their Build or BuildRun specs, and the controller will merge these overrides at runtime when generating the Tekton TaskRun with BuildRun overrides taking precedence over Build overrides, which in turn override strategy defaults.

Out of scope

• Modifying BuildStrategy or ClusterBuildStrategy resources - This feature allows overriding resources at Build/BuildRun level; it does not change how strategies define default resources.
• Using Tekton's task-level `computeResources` - We will not use Tekton's resource allocation where requests are divided among steps. [Follow-up feature]
• Using Tekton's `stepSpecs` override mechanism - We implement our own Shipwright-native override mechanism rather than passing through to Tekton's `stepSpecs`.
• Validating whether requested resources fit within namespace `ResourceQuota` or `LimitRange` constraints is out of scope; Kubernetes handles this at pod creation time.
• Suggesting or automatically calculating optimal resources based on build history or image size is not part of this proposal.
• Using Kubernetes native pod-level resource specification.`Kubernetes v1.34 [beta]`(enabled by default). Resources are shared across all containers in pod. This requires PodLevelResources feature gate enabled; build steps run sequentially so no concurrent sharing benefit. No per-step control. [Follow-up feature]
• Overriding resources for Shipwright-managed supporting steps (Git clone, image-processing).

  Approach (Required)

1. Add `StepResourceOverride` struct and `StepResources` field to `Strategy` struct in `pkg/apis/build/v1beta1/buildstrategy.go`.

2. Update CRD schemas in `deploy/crds/shipwright.io_builds.yaml` and `deploy/crds/shipwright.io_buildruns.yaml`.

Broadly, these are the steps:

1. Merge logic(Reconciler): When generating a TaskRun, the controller merges resources with the following precedence: BuildRun.stepResources > Build.stepResources > Strategy.steps[].resources.

2. Validation: Before creating the TaskRun, validate that step names exist in the referenced strategy.

3. TaskRun generation: Apply merged resources to `TaskRun.spec.taskSpec.steps[].computeResources`.

Dependencies

Acceptance Criteria (Mandatory)

Unit Tests 

• Test merge logic to verify correct precedence (BuildRun > Build > Strategy defaults)
• Test validation to ensure invalid step names are rejected with appropriate error messages
• Test TaskRun generation correctly applies merged resources to steps
• Test edge cases: empty `stepResources`, partial overrides (non-overridden steps retain strategy defaults), nil values, multiple resource types (CPU, memory, ephemeral-storage)

Integration Tests 

• Create a Build with `stepResources`, trigger a BuildRun, verify the generated TaskRun contains correct resource values
• Test with both `BuildStrategy` and `ClusterBuildStrategy` to ensure feature works for both

E2E Tests

• Create Build with `stepResources` overrides, run BuildRun, verify build completes successfully
• Create Build with overrides, then BuildRun with different overrides, verify build completes with BuildRun values applied

  INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met