Running regressions on a clean linux machine


BitKeeper comes with an extensive regressions suite and new changes should be validated against those tests and the tests should be extended for any new code.

The regressions make some assumptions about the machine where they are run. This guide explains how to configure your machine. We are trying to remove some of these requirements so this document will get updated in the future.


Install bk

Some tests assume Bitkeeper is installed on the current machine in the current user’s PATH.

Work from a BitKeeper repository

The regressions assume they are running from the official BitKeeper repository and do not work correctly when run from an unpacked tarball or a git clone. So do something like this:

bk clone bk:// dev
cd dev/src

Create a /build

The regressions expect a /build filesystem that is writable by anyone. A simple way to create this is:

mkdir /tmp/build
sudo chmod 1777 /tmp/build
sudo ln -s /tmp/build /build

(This may not be necessary, need to test that)

Need a full hostname

Your machine needs to have a full domain name that BitKeeper knows about.
The command bk gethost -r needs to return a domain name that resolves to the current machine.

An easy way to do this on most machines is to edit /etc/hosts to add a domain:	localhost	vm1

SSH connections to the localhost need to work

The code expects that ssh localhost date and ssh HOST date both work without prompting for a password. Usually, that can be fixed by running:

ssh-copy-id localhost

Running regressions

Run regressions like this:

cd src
make -j p
cd t
make -j6 -k
ls output/BAD.t.*

I updated these instructions to state that regressions assume they are running from a bitkeeper repository. Running regressions from a source tarball will fail.

Perhaps I should change the make src-tar make target to skip the src/t component?

I had made regressions run from a tarball. Maybe this is new?


Can you share how you made it? I have some problems.

What I mean is that when bk went out as OSS regressions ran in a tarball. Unless something was broken recently I don’t see why they shouldn’t run now.

I’m on vacation so I don’t have a computer with me, but one thing I can think of is if you were running regressions by running doit instead of make. I remember only testing using make.

For me, at least 2 test fails, when using make tests on a tarball. When you came back for vacation can you check again, in case I have not sorted out the problems.

One of the problems was in t.importcvs when running the CVS test we require you to comment out the cvsadmin group. That was fine for our machines, but obviously not going to work in general. We try to run ‘cvs admin’ and that will fail if that group is defined and the user is not in it.

The test should be changed to check if the user has membership in that group and if not skip the test rather than erroring.

1 Like

FWIW, I just tried this with the latest dev-oss, which I’m not sure has been released, and it seems to work (modulo some bk not found warnings).

vagrant@vagrant:~/bk-20160708162826/src$ make -j4 test
DO_REMOTE=NO make -C t
make[1]: bk: Command not found
make[1]: Entering directory `/home/vagrant/bk-20160708162826/src/t'
make[1]: bk: Command not found
make[1]: bk: Command not found
make[1]: bk: Command not found
make[1]: bk: Command not found
Test (50.2 secs)

BTW, what I did was simply:

$ curl <latest tarball> | tar xvfz -
$ cd bk-*/src
$ make -j12
$ make -j12 test

I used the Vagrantfile configuration in the box subdirectory (which I had to update for the latests dependencies).