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

s2i: Use COPY --chown Flag in Dockerfile

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • s2i-1.4
    • source-to-image
    • False
    • None
    • False

      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 using s2i to build applications I want s2i to use the `COPY --chown` flag when adding source code to the container image.

      Background (Required)

      <Describes the context or background related to this story>

      Part of the s2i Dockerfile generation process (`s2i generate` or `s2i build --as-dockerfile`) copies source code so it can be assembled into the running application. It currently does this in 4 steps:

      USER root
      COPY upload/src /tmp/src
      RUN --chown -R <assemble-uid>:0 /tmp/src
      USER <assemble-uid>
      

      Currently supported versions of podman, buildah, and docker support the `--chown` flag for COPY instructions, which can collapse the 4 steps above to 1:

      COPY --chown=<assemble-uid>:0 upload/src /tmp/src
      

      This reduces the number of image layers in the output container image, and allows the build tool of choice to optimize the `COPY` instruction.

      Out of scope

      <Defines what is not included in this story>

      Approach (Required)

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

      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

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

                Created:
                Updated: