Testing HTCondor On Linux

Starting in 8.9.3, HTCondor tests can be invoked using the ctest framework.

Building HTCondor

This is a simple primer for building HTCondor; refer to BuildingHtcondorOnLinux for more in-depth build instructions.

  1. 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

  2. Compiling the code and tests.(See BuildingHtcondorOnLinux 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

Running ctest

From the build directory, after creating a release directory via make install (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 Testing/Temporary/LastTest.log.

NOTE: Some tests failures cause a personal condor_pool to be leaked. If you have issues re-running the tests, try doing killall condor_master.

Some ctest 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

  1. specifying a "--hostname" flag in Docker is NOT compatible with using "--network host", thus it is recommended to use the default NAT networking.
  2. 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.
  3. 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.