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

Support shallow cloning in Git

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • shipwright
    • None
    • Support shallow cloning in Git
    • False
    • None
    • False
    • Not Selected
    • To Do
    • 100% To Do, 0% In Progress, 0% Done

      Story (Required)

      We are using buildconfigs to build our images using S2i. We are building our images based on a specific commit ID of a git repository. We figured that, when we use spec.source.git.ref Openshift clones whole git repository with all the history. When we compare size of the source code that we need with ".git" folder, we see that there is big difference in size. When we build an image using spec.source.git.ref, it seems builded image also have git history and its size is unnecessarily large.

      When we delete "ref" part or when we do a binary build after cloning source code to a local filesystem we see that our final images are much thinner.

      We also tried using `OpenShift Builds` but it also not using Shallow cloning. 

      Background (Required)

      <Describes the context or background related to this story>

      Out of scope

      <Defines what is not included in this story>

      Approach (Required)

      1. Shallow clone for specific commit ID
        git init
        git clean -d -f
        git remote add <app_name> <repo_url>
        git fetch --depth 1 <app_name> <commit_id>
        git checkout FETCH_HEAD

        Dependencies

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

      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>

      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

              rh-ee-asatyam Ayush Satyam
              rhn-support-sburhade Satyam Burhade
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: