Testing HTCondor On Linux
Starting in 8.9.3, HTCondor tests can be invoked using the
This is a simple primer for building HTCondor; refer to BuildingHtcondorOnLinux for more in-depth build instructions.
Get the source code from any of the following locations:
git clone https://github.com/htcondor/htcondor.git # Source code can also be obtained from tarballs on HTCondor's website
Compiling the code and tests.(See
for more details on building the code and pre-requisites)
cd htcondor # change directory to the root of source tree.. mkdir __build # make an out-of-source build destination cd __build ../configure_uw .. make install
From the build directory, after creating a release directory via
(or equivalent), run:
ctest -j 20
That's it! The tests should be idempotent - it should be safe to re-run them as many times as desired.
If all the tests fail and the failures happened very quickly (i.e., no condor was launched), the first place to check is
: Some tests failures cause a personal
to be leaked. If you have issues re-running the tests, try doing
tips and tricks:
# Run 40 test cases in parallel -- depending on your machine/container, # you may be able to run as many as 80 or as few as 10 before tests fail due to overloading ctest -j 40 # Run all tests matching the regex `cmr`: ctest -R cmr # Run all tests except those matching `cmr`: ctest -E cmr
Running ctest in a docker container
When running the condor tests inside a docker container, the container must be started with special flags for some of the tests to work. While we hope to fix the tests in the future, for now, starting with a hostname like so
docker run --hostname docker.cs.wisc.edu <rest of arguments>
is needed. This is because many tests assume the hostname are FQDNs, and there will be many test timeouts and failures if the hostname of the container has no dots in it. Note that
- specifying a "--hostname" flag in Docker is NOT compatible with using "--network host", thus it is recommended to use the default NAT networking.
- using the default NAT networking also has the nice property of making another virtual interface.... because running the test suite can consume 5k ephemeral network ports, creating a virtual network interface will help prevent the bare metal server from running out of ports.
- the unit_test_sinful looks for ipv6 addresses, which most docker containers do not fully support with NAT networking, and thus running in Docker with NAT networking will cause this test to be skipped.