After all components are installed, and before invoking eMake, you need to configure CloudBees Build Acceleration to ensure accurate, reliable builds. Before invoking eMake, you need to set up CloudBees Build Acceleration to ensure accurate, reliable builds.
Defining your build
Before using CloudBees Build Acceleration, precisely define which components go into your build. Generally, a build has three input types:
SOURCES + TOOLS + ENVIRONMENT = BUILD
Build sources
Build sources include all compiled or packaged files to build your product. For example, these sources include:
-
Intermediate files generated during the build (for example, headers or IDL files)
-
Makefiles and scripts that control the build
-
Third-party source files read during the build
-
Any file read by the build in source control
Build tools
Tools used to create build output include make, compilers, linkers, and anything else operating on the sources during the build:
-
Executable post-process tools (for example, strip )
-
Static analyzers (for example, lint ) if they run as part of the build
-
Packaging tools (for example, tar or zip )
Sometimes the distinction between sources and tools is blurred. Consider these examples:
-
A utility executable compiled from your sources during the build, run during later steps, but not part of final output
-
Header source files that are part of the compiler (for example,
stdio.h)or a third-party package, but not under source control
In this context, sources are those files that might change from one build to the next. Thus, a utility executable compiled from your sources as part of the build is considered a source.
By contrast, tools change infrequently—tools are often configured once and served from a central location (for example, an NFS share). A standard header such as stdio.h is usually considered part of the tool suite.
The distinction between inputs that can change between builds (sources) and inputs that can safely be assumed to be constant (tools) becomes important when configuring CloudBees Build Acceleration virtualization.
Build environment
Your operating system environment is an essential part of your build. The operating system is easy to overlook because the environment usually is configured once per host and then ignored as long as builds function normally. But when a build is distributed across a shared cluster, it is important to identify which parts of the operating system could affect the build. Some inputs to consider include:Your operating system environment is an essential part of your build. The operating system is easy to overlook because the environment usually is configured once per host and then ignored as long as builds function normally. It is important to identify which parts of the operating system could affect the build. Some inputs to consider include:
-
User environment variables
-
System registry (Windows only)
-
Operating system version (including patches or service packs)
-
User account and user permissions
-
Host-specific attributes (for example, machine name, network configuration)
For each of these inputs, consider what impact (if any) they will have on the build.
Generally, some environment variables require correct settings for a build (for example, PATH or variables that specify output architecture or source/output file locations).
Another common example of how the operating system can affect the build occurs with the use of tools that require license management. If a tool license (for example, a compiler) is host-locked or it requires contacting a license server to operate, ensure the compiler on the host can acquire the license also (for example, cluster host names could be configured as valid license server clients).
Extended file attributes (xattr) are not supported. Attempting to query or set extended attributes for a file returns an ENOTSUPP (“Operation not supported”) error.
|
Configuring your build
After defining your build environment and identifying all of its inputs, configure the cluster and eMake so the system correctly virtualizes:
Some cases of virtualization or distribution of specific job steps are not desirable. For these cases you can configure CloudBees Build Acceleration to:
-
Run an individual command from the Agent back on the host system, using the “proxy command” function. See Using the Proxy Command.
-
Prevent remote job execution by using the
#pragma runlocalfunction. See Running a Local Job on the Make Machine.