Story (Required)

<Describes high level purpose and goal for this story. Answers the questions: Who is impacted, what is it and why do we need it? How does it improve the customer’s experience?>

As a developer trying to build applications with OpenShift I want the console to show sample builds using the buildpacks build strategies so that I can quickly get started.

Background (Required)

<Describes the context or background related to this story>

OpenShift provides the `ConsoleSampleYAML` custom resource, which integrates sample code into developer console. Users can use the samples to quickly generate new Kubernetes objects (any type supported, including CRDs).

Out of scope

<Defines what is not included in this story>

• Sample for s2i and buildah. See BUILD-997
• Sample that uses a `BuildRun` object

Approach (Required)

<Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

TBD

Dependencies

<Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

• ConsoleSampleYAML this has existed in OpenShift for a long time.
• Tech preview of Buildpacks strategy - BUILD-848

Acceptance Criteria (Mandatory)

<Describe edge cases to consider when implementing the story and defining tests>

<Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

• Sample `Build` YAML for buildah strategy builds source code from GitHub and pushes to the OpenShift internal registry (aka an imagestream).
• Sample `Build` YAML for s2i strategy builds source code from GitHub using an appropriate s2i builder image, and pushes it to the internal registry
• Samples document any values that are "templated" and require users to provide a replacement value. Example - a namespace name used in the output image reference.
• Verification that the templates are functional and a resulting BuildRun produces a valid output image.

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