Uploaded image for project: 'OpenShift Builds'
  1. OpenShift Builds
  2. BUILD-948

Add Build Cache Volume to Supported Build Strategies

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Obsolete
    • Icon: Normal Normal
    • None
    • builds-1.0
    • builds-catalog
    • None
    • 8

      Story (Required)

      As a developer trying to build images with Shipwright I want Red Hat supported build strategies to support caching of dependencies

      <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?>

      Background (Required)

      <Describes the context or background related to this story>

      Follow up from BUILD-825 - we should add a build cache volume to all of our supported build strategies, to support caching of container image layers.

      We should first aim to support caching of buildah's container image layers (those stored in /var/lib/containers). We should future-proof our conventions/approach so that the same volume can be used for application dependencies (maven, NodeJS, etc.)

      Out of scope

      <Defines what is not included in this story>

      • General approach for application dependency caching (Maven, NodeJS, etc.)
      • Build strategies that extend buildah/s2i (ex: Quarkus)
      • CI process for our build catalog - is this a blocker?

      Approach (Required)

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

      • Add "build-cache" volume to supported build strategies
      • Mount build cache volume to any buildah step, in the /var/lib/containers directory
      • When mounting, use subPath feature to separate container image layers from other cacheable content (ex: set to cache/containers)
      • Update the build strategies in our operator.

      Dependencies

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

      • CI process for build catalog?
      • Others TBD

      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>

      • buildah and source-to-image strategies include a build volume for caching
      • Builds can use a (pre-created) persistentVolumeClaim as a volume
      • Product docs updated to show users how to add a PVC to our buildah and s2i strategies.
      • buildah build steps do not pull cached layers (this should reduce build times of repeated build runs).

      INVEST Checklist

      Dependencies identified

      Blockers noted and expected delivery timelines set

      Design is implementable

      Acceptance criteria agreed upon

      Story estimated

      Initial estimate:

      • Engineering: 3
      • Docs: 3
      • QE: 0 or 1 assuming CI is in place.
      • PXE: 2 - demo should be included as part of release technical enablement

      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

              Unassigned Unassigned
              adkaplan@redhat.com Adam Kaplan
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: