Arvados

This branch can be simplified by reusing existing infrastructure. There is some code in this repository to test the sso packages. It can be run like this:

First build the package:

WORKSPACE=<your-workspace> ./run-build-packages-one-target.sh --target ubuntu1204 --command run-build-packages-sso.sh

Then run the tests:

WORKSPACE=<your-workspace> ./run-build-packages-one-target.sh --target ubuntu1204 --command run-test-packages-sso.sh

This branch should be refactored to follow the same pattern: write an equivalent of run-test-packages-sso.sh that runs the tests you want to run, and leave the docker side of things up to run-build-packages-one-target.sh and run-build-packages-all-targets.sh.

Reviewing 7370-package-install-testing:

• pushed one small commit on the branch to make dpkg-scanpackages more quiet if there are many versions of a package available, please include that when you merge.

• package tests fail for centos6, debian7, debian8 with a variety of errors.

Other than that, LGTM.

OK there is now a test-packages standalone step.

Right now that is running off a one-time copy of the packages built by build-packages (as of just now); once this thing actually passes I'll move it into the build-packages step, before the upload to the apt repository. That way it will share the packages directory (symlinking doesn't work because a symlink doesn't survive a docker volume mount).

Peter, you can already see the CentOS6 failure in

https://ci.curoverse.com/job/test-packages/5/console

In local testing I'm seeing the same, also for the Debian tests. You should be able to reproduce that?

Thanks,
Ward.

The python-llfuse_0.41.1 package on Jenkins was last built Aug 23.
The python-arvados-fuse_0.1.20150916213104 package on Jenkins was last built Sep 16.

When I compare these packages to the ones that I build locally, they are different.

So I think what is going on is that we have made fixes to the package building, but because we don't have package metadata versioning, the actual packages that are automatically built and distributed by Jenkins are not getting rebuilt. Which means the package install testing is correct in identifying that there is a problem.

I logged into the Jenkins server and manually ran the tests for debian7, debian8, ubuntu1204 and ubuntu1404 and they all passed, so it is just the out-of-date centos6 packages that are holding up the build, because the centos6 test runs first and the script is quitting on first failure.

Peter Amstutz wrote:

So I think what is going on is that we have made fixes to the package building, but because we don't have package metadata versioning, the actual packages that are automatically built and distributed by Jenkins are not getting rebuilt.

Correct. Fixed manually in c271c93c. New packages now correctly declare their dependencies, and pass the tests.