<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I've posted the Build Avoidance wiki<br>
      <br>
<a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/StarlingX/Developer_Guide#Build_Avoidance">https://wiki.openstack.org/wiki/StarlingX/Developer_Guide#Build_Avoidance</a><br>
      <br>
      Reviews welcome.<br>
      <br>
      We can relocate it if there is a better home folks can suggest.<br>
      <br>
      Scott<br>
      <br>
      <br>
      <br>
      On 18-08-27 04:17 PM, Scott Little wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:06fb400c-4e93-c765-6385-9e579e2b3ae7@windriver.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <p>Build Avoidance, a build tool improvement.<b><br>
        </b></p>
      <p><b>Purpose:</b></p>
      <p>   Greatly reduce build times after a repo sync for designers
        working within a regional office.  For a new workspace,
        build-pkgs typically requires 3+ hours, build avoidance
        typically reduces this step to ~20min.  <br>
      </p>
      <p><b>Limitations:</b></p>
      <p>   Little or no benefit for designers who refresh a
        pre-existing workspace at least daily. (download_mirror.sh, repo
        sync, generate-cgcs-centos-repo.sh, build-pkgs, build-iso).</p>
      <p>   Not likely to be useful to solo designers, or teleworkers
        that wish to compile on there home computers.  WAN speeds are
        generally to slow.<br>
      </p>
      <p><b>Method (in brief):</b></p>
      <p>1) Reference builds<br>
      </p>
         - A server performs a regular (daily?), automated builds using
      existing methods.  Call these the reference builds.<br>
         - The builds are timestamped, and preserved for some time. 
      (weeks?)<br>
         - A build CONTEXT is captured, consisting of the SHA of each
      and every git that contributed to the build.<br>
         - For each package built, a file shall capture he md5sums of
      all the source code inputs to the build of that package.<br>
         - All these build products are accessible locally (e.g. a
      regional office) via rsync (other protocols can be added later)<br>
      <br>
      2) Designers<br>
         - build-pkgs --build-avoidance   ... will request a build
      avoidance build.<br>
         - Additional arguments, and/or environment variables, and/or a
      config file unique to the regional office, are used to specify a
      URL to the reference builds.  <br>
         - build-pkgs will:<br>
           = From newest to oldest, scan the CONTEXTs of the various
      reference builds.  Select the first (most recent) context which
      satisfies:  For every git, the SHA specified in the CONTEXT is
      present.<br>
           = The selected context might be slightly out of date, but not
      by more than a day (assuming daily reference builds). <br>
           = If the context has not been previously downloaded, then
      download it now.  Meaning download select portions of the
      reference build workspace into the designer's workspace.  This
      includes all the SRPMS, RPMS, MD5SUMS, and misc supporting files. 
      (~10 min over office LAN)<br>
           = The designer may have additional commits not present in the
      reference build, or uncommitted changes.   Affected packages will
      identified by the differing md5sum's, and the package is re-built.
      (5+ min, depending on what packages have changed)<br>
      <br>
         <br>
      <p><b>Requirement:</b></p>
         - The regional office implements an automated build that pulls
      the latest StarlingX software and builds it on a regular basis. 
      e.g. a daily.  Perhaps implemented by Jenkins, cron, or similar
      tools.<br>
         - Each build is saved to a unique directory, and preserved for
      a time that is reflective of how long a designer might be expected
      to work on a private branch without syncronizing with the master
      branch.   e.g. 2 weeks.<br>
         - The MY_WORKSPACE directory for the build shall have a common
      root directory, and a leaf directory that is a time stamp of
      format YYYY-MM-DD_hh-mm-ss.  e.g.
      MY_WORKSPACE=/localdisk/loadbuild/jenkins/StarlingX/2018-07-19_11-30-21<br>
         - Designers can access all build products over the internal
      network of the regional office.  The current prototype employs
      rsync. Other protocols that can efficiently share/copy/transfer
      large directories of content can be added as needed.<br>
      <p><br>
      </p>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Starlingx-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Starlingx-discuss@lists.starlingx.io">Starlingx-discuss@lists.starlingx.io</a>
<a class="moz-txt-link-freetext" href="http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss">http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>