Epic Goal

• Document migration approaches for BuildConfig users to Shipwright-based APIs for the simple use cases that are currently supported in Shipwright.

Why is this important?

• Customer adoption will be limited if they currently use BuildConfigs and do not have a clear way to consume Shipwright

Scenarios

1. Migrate simple Docker strategy BuildConfigs to Shipwright builds via the buildah build strategy
2. Migrate s2i strategy BuildConfigs to Shipwright builds via the s2i build strategy

Acceptance Criteria (Mandatory)

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. Red Hat supported buildah build strategy
2. Red Hat supported s2i build strategy

Previous Work (Optional):

1. ...

Open questions::

1. ...

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment