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.
Setup
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://bkbits.net/u/bk/dev 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:
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:
127.0.0.1 localhost
127.0.1.1 vm1 vm1.example.com
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?
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.
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 t.a.simple-interface.no-repo (50.2 secs)