This page describes how to use the NSS try server.
(You probably want to push to nss-try before pushing to the main NSS repository.)
- 1 Pushing to nss-try
- 2 Using nss-try.sh
- 3 Using try syntax
- 4 Try syntax implementation
Pushing to nss-try
An account level 1 commit access is required. (Get it here.)
Create a new entry in the
[paths] section of your
nss-try = ssh://firstname.lastname@example.org@hg.mozilla.org/projects/nss-try
Now every time you want to push a patch to nss-try you can simply do:
$ cd $nss-directory/ $ hg push -r . -f nss-try
Note: Local changes will not be pushed, all code that you want to test must be commited in some way. For example, you could use the mq extension and commit your change to a local mq patch (hg qnew).
Your try job will show up on the nss-try dashboard in a second.
$ ~/git/nss-tools/nss-try.sh (... detailed instructions ...) $ ~/git/nss-tools/nss-try.sh -e all -t all -u all
Using try syntax
This section describes how to use try syntax to push your patch to nss-try and run only a subset of all available Taskcluster tests.
try: -b do -p all -u all -t all -e all
This will run all available Taskcluster builds and tests and is equivalent to not specifying any try syntax at all.
Available options are:
-b do (debug and opt) [default is "do" if omitted] -p linux,linux64,linux-make,linux64-make,linux-fuzz,linux64-fuzz,linux64-asan,linux64-fips,win64,win64-make,win,win-make,aarch64 (or "all" or "none") [default is "all" if omitted] -u bogo,crmf,chains,cipher,db,ec,fips,gtest,interop,lowhash,merge,sdr,smime,tools,ssl (or "all" or "none") [default is "none" if omitted] -t clang-format,scan-build,hacl,saw,coverage (or "all" or "none") [default is "none" if omitted] -e all (or "none") [default is "none" if omitted]
Build types (-b / --build)
There are two available build types:
opt. If you want both use
-b do, for only debug builds use
-b d, and use
-b o for only optimized builds.
Platforms (-p / --platform)
The currently available platforms are
aarch64. Specify any combination of those, like
-p linux,win64, to choose the platforms your patch should be tested on. If you want to test all platforms use
-p all, if you want no platforms (which is only useful when you want only tools, see below) then use
Unit tests (-u / --unittests)
The currently available test suites are
ssl. Specify any combination of those, like
-u ec,gtest, to choose the test suites to run with your patch. If you want to run all test suites use
-u all, if you want no tests use
Tools (-t / --tools)
The currently available tools are
coverage. Specify any combination of those, like
-t clang-format,scan-build, to choose the tools to run with your patch. If you want to run all tools use
-t all, if you want no tools use
Extra builds (-e / --extra-builds)
none to enable or disable extra builds. The number and type of extra builds varies per platform.
Try syntax implementation
This section describes how the try syntax is implemented for nss-try.
After pushing a new changeset to nss-try or the main NSS repository, Taskcluster will spawn a new decision task
D that may then extend the task graph, i.e. decide what to build and which tests to run. NSS uses a Node.JS app to do that:
The file above will build the complete task graph, for all build types, platforms, test suites, and tools. Before this is sent back to Taskcluster however, we will filter all tasks by the given try syntax, if any. The code for that filter can be found at:
Whenever you're adding or changing some piece of code in the try syntax filter, please push to nss-try before landing to ensure it's all working as expected. All changes to the NSS Taskcluster CI can be tested on nss-try before landing on the main repository.