Javascript:Automation Builds

The Builds

All of the SM(...) builds appearing on Treeherder are JS shell-only builds. Currently, they all

• Checkout the source
• Configure using a set of options appropriate to the specific build
• Build (by simply invoking make)
• Run tests, possibly differently depending on the specific build

All of this is done by running the shell script js/src/devtools/automation/autospider.sh <variant>, where <variant> is one of the filenames in js/src/devtools/automation/variants/.

Reproducing a build

You should be able to closely replicate a TH build by running autospider.sh yourself. For example, to replicate SM(cgc), you could be anywhere within your checkout, and run

 <gecko-root>/js/src/devtools/automation/autospider.sh --clobber compacting

The default objdir is <gecko-root>/obj-spider. You can change it by setting the $OBJDIR environment variable.

To narrow the test down, delete some of the lines at the end of autospider.sh that run the various tests.

Mapping variants to SM(...) names

There is no good way. They're hardcoded in the Treeherder code. Many of them even show up in multiple repos. Here's a snapshot:

• SM(cgc) - compacting
• SM(p) - plain or plaindebug
• SM(arm) - arm-sim or arm-sim-osx
• SM(arm64) - arm64-sim
• SM(exr) - exactrooting
• SM(r) - rootanalysis
• SM(pkg) - Standalone SpiderMonkey package.
• SM(tsan) - tsan

Specific Build Information

SM(pkg)

The SM(pkg) builds create a tarball of all the sources used to make a standalone SpiderMonkey library and shell, untar it somewhere else, and then runs the autospider command listed above. To reproduce this packaging and unpackaging behavior, you can run this command:

 <gecko-root>/testing/taskcluster/scripts/builder/build-sm-package.sh

SM(tsan)

sm-tsan is a dynamic thread safety checker, which means that any given run will only report a subset of issues. Also, we have a number of errors currently in the codebase that it will allow through without turning the build red. These are listed in

 <gecko-root>/js/src/devtools/automation/variants/tsan

under the 'expect-errors' key. These are a list of filename,function pairs. (We cannot use a line number because it would change whenever lines are added/removed.) For a given build, errors are summarized in a tsan_summary.txt artifact, and the detailed stack information produced by tsan will be bundled up in a tsan.tar.gz file containing per-pid outputs.

The mrgiggles server is running a script that downloads and categorizes the observed failures, but it isn't done yet (it misses some pushes), and it does not yet expose the information it collects. If you're looking into a specific failure, you can either dig it out of tsan.tar.gz, or ask sfink for the detailed failure information. (mrgiggles watches for job completions, downloads tsan.tar.gz, and records the failure stacks in a file named after the filename, line number, and function name.)