Difference between revisions of "StarlingX/Developer Guide"
Scott.little (talk | contribs) (→Build Avoidance) |
|||
| (13 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| + | |||
| + | |||
| + | See the [https://docs.starlingx.io/contributor/index.html StarlingX Build Guide] for the latest information regarding StarlingX development practices. | ||
| + | This wiki page has been deprecated. | ||
| + | |||
| + | <!-- | ||
| + | |||
This section contains the steps for building a StarlingX ISO from Master branch. | This section contains the steps for building a StarlingX ISO from Master branch. | ||
| Line 67: | Line 74: | ||
<ol start="1"><li>Under your $HOME directory, clone the <stx-tools> project | <ol start="1"><li>Under your $HOME directory, clone the <stx-tools> project | ||
| − | <source lang="sh">$ | + | <source lang="sh"> |
| − | + | $ git -C $HOME clone https://git.starlingx.io/stx-tools | |
</source></li></ol> | </source></li></ol> | ||
| Line 84: | Line 91: | ||
=== Setup Repository Docker Container === | === Setup Repository Docker Container === | ||
| − | Run the following commands under a terminal identified as "One". <br> | + | Run the following commands under a ''terminal identified as'' "'''One'''". <br> |
<ol start="1"><li>Navigate to the ''<$HOME/stx-tools>/centos-mirror-tool'' project directory: | <ol start="1"><li>Navigate to the ''<$HOME/stx-tools>/centos-mirror-tool'' project directory: | ||
| Line 395: | Line 402: | ||
* A server in the regional office performs a regular (daily?), automated builds using existing methods. Call these the reference builds. | * A server in the regional office performs a regular (daily?), automated builds using existing methods. Call these the reference builds. | ||
* The builds are timestamped, and preserved for some time. (a few weeks) | * The builds are timestamped, and preserved for some time. (a few weeks) | ||
| − | * A build CONTEXT is captured | + | * A build CONTEXT is captured. This is a file produced by build-pkgs at location '$MY_WORKSPACE/CONTEXT'. It is a bash script that can cd to each and every git and checkout the SHA that contributed to the build. |
| − | * For each package built, a file shall capture he md5sums of all the source code inputs to the build of that package. | + | * For each package built, a file shall capture he md5sums of all the source code inputs to the build of that package. These files are also produced by build-pkgs at location '$MY_WORKSPACE/<build-type>/rpmbuild/SOURCES/<pkg-name>/srpm_reference.md5'. |
* All these build products are accessible locally (e.g. a regional office) via rsync (other protocols can be added later) | * All these build products are accessible locally (e.g. a regional office) via rsync (other protocols can be added later) | ||
</li> | </li> | ||
| Line 428: | Line 435: | ||
** Using command line args to specify location of your reference build<source> | ** Using command line args to specify location of your reference build<source> | ||
build-pkgs --build-avoidance --build-avoidance-dir /localdisk/loadbuild/jenkins/StarlingX_Reference_Build --build-avoidance-host stx-builder.mycompany.com --build-avoidance-user jenkins | build-pkgs --build-avoidance --build-avoidance-dir /localdisk/loadbuild/jenkins/StarlingX_Reference_Build --build-avoidance-host stx-builder.mycompany.com --build-avoidance-user jenkins | ||
| + | </source> | ||
| + | * Prior to your build attempt, you need to accept the host key. This will prevent rsync failures on a yes/no prompt. (you should only have to do this once)<source> | ||
| + | grep -q $BUILD_AVOIDANCE_HOST $HOME/.ssh/known_hosts | ||
| + | if [ $? != 0 ]; then | ||
| + | ssh-keyscan $BUILD_AVOIDANCE_HOST >> $HOME/.ssh/known_hosts | ||
| + | fi | ||
</source> | </source> | ||
* build-pkgs will: | * build-pkgs will: | ||
| Line 435: | Line 448: | ||
** 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) | ** 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) | ||
</li> | </li> | ||
| + | |||
| + | * What if no valid reference build is found? Then build-pkgs will fall back to a regular build. | ||
</ol> | </ol> | ||
| Line 529: | Line 544: | ||
... | ... | ||
</source> | </source> | ||
| + | |||
| + | One final wrinkle. | ||
| + | We can ask build avoidance to preferentially use the full build day rather than the most recent build, as the reference point of the next avoidance build via use of '--build-avoidance-day <day-name>'. e.g. substitute this line into the above. <source> | ||
| + | build-pkgs --build-avoidance --build-avoidance-dir $BUILD_AVOIDANCE_DIR --build-avoidance-host $BUILD_AVOIDANCE_HOST --build-avoidance-user $USER --build-avoidance-day $FULL_BUILD_DAY | ||
| + | |||
| + | # or perhaps, with a bit more shuffling of the above script. | ||
| + | |||
| + | build-pkgs --build-avoidance --build-avoidance-dir $BUILD_AVOIDANCE_DIR --build-avoidance-host $BUILD_AVOIDANCE_HOST --build-avoidance-user $USER --build-avoidance-day $LAST_FULL_BUILD_DAY | ||
| + | </source> | ||
| + | The advantage is that our build is never more than one step removed from a full build (assuming the full build was successful).<br> | ||
| + | The disadvantage is that by end of week the reference build is getting rather old. During active weeks, builds times might be approaching that of a full build. | ||
| + | |||
| + | --> | ||
Latest revision as of 18:46, 16 July 2019
See the StarlingX Build Guide for the latest information regarding StarlingX development practices.
This wiki page has been deprecated.
