Commits on Jan 25, 2019

1. Customize builds for different platforms …

   This change provides the ability to build versions of the appliance
   customized for different platforms (hypervisors and cloud providers).
   This is done by installing a different versions of the delphix-platform
   and delphix-kernel packages depending on which platform we are
   building for. Since we only want to have a single upgrade image per
   variant, this change also adds a second stage to the build which
   combines the live-build output for multiple platform versions of the
   same variant into a single upgrade tarball.
   
   The live-build stage of the build is now run by invoking 'gradle' with a
   a target which is a combination of variant and platform, e.g.
   'gradle buildInternalDevEsx'.
   
   The second stage of the build is run by invoking 'gradle' with a variant
   as a target, e.g. 'gradle buildUpgradeImageInternalDev'. When the second
   stage is run, an environment variable 'AWS_S3_URI_LIVEBUILD_ARTIFACTS'
   can be passed. If it is used, previously built live-build artifacts will
   be downloaded from the provided S3 URIs, and placed in
   live-build/build/artifacts as if they had been built locally. If it is
   not used, live-build will be invoked for each of the hypervisors
   specified in the 'DELPHIX_PLATFORMS' environment variable.
   
   A couple notes about the implementation:
   
    1. This change replaces the Make build with a Gradle one. The build
       logic needed for this change was difficult to express using Make and
       resulted in a Makefile which was very difficult to understand. The
       use of Gradle make handling this build logic more straightforward
       and also made it possible to add better support for incremental
       builds.
    2. This change removes the idea of the 'base' live-build variant. The
       base variant contains the kernel, and because the kernel differs
       between hypervisors, it cannot be shared between different hypervisor
       builds. It would be possible to have a different version of the base variant
       per hypervisor, and share that between different variants built for
       the same hypervisor. However, this likely isn't worth the effort
       because it doesn't help in either of the two most common use cases:
        - Building via a jenkins job: when building via Jenkins, each
          variant will now be built via a sub-job running on its own build
          VM, so the base would be rebuilt for each sub-job anyway.
        - Developers iterating on changes on personal build VMs: in this
          case developers are most likely to be building a single variant,
          in which case the 'base' variant would be less likely to be
          re-used.
    3. We no longer do the live-build in place (that is, directly in
       live-build/variant/<variant>/). Now that we have multiple builds per
       variant, we need to make sure that intermediate live-build
       artifacts from one build are not incorrectly re-used in the next
       build of the same variant, which might be for a different
       hypervisor. The simplest way to accomplish this is just to do the
       live-build in a throw-away directory.
   
   In light of these two changes, some of current layout of the
   repository no longer makes sense, so this change re-arranges a number
   of files in the repo, particularly in the live-build/ directory.

   

   jgallag88 committed Jan 25, 2019
   Configuration menu

   • View commit details
   • Copy full SHA for ebd884a
   • Browse repository at this point

   Copy the full SHA

   ebd884a View commit details

   Browse the repository at this point in the history