canonical-ci-engineering team mailing list archive

[Evan Dandrea <evan.dandrea@xxxxxxxxxxxxx>]

Dave asked for some instructions on doing end-to-end testing of the
staging daisy, retracers, and errors. This should do it, though don't
hesitate to follow up with questions.

First, make sure we have an empty database. Something akin to this
will work, and please do feel free to modify it to support your needs
as an MP - I want us to stay consistent:

http://bazaar.launchpad.net/~daisy-pluckers/error-tracker-deployment/trunk/view/head:/test/purge-db

Next, grab a copy of the old error-tracker-deployment code. Dave, can
we get your juju-deployer configs folded into this? I'd like us to be
able to deploy in Canonistack the same way you're deploying to
Prodstack.

bzr branch lp:error-tracker-deployment
cd test
mkdir -p reports
chmod 777 reports
./fetch-test-crashes

You should have lots of crashes in test-crashes/ now. Finally, run a
local whoopsie pointed at the staging daisy and then tell the
integration test runner to feed crashes to it, then check the result
on errors.staging.u.c.

sudo stop whoopsie
CRASH_DB_URL=https://daisy.staging.ubuntu.com
CRASH_DB_IDENTIFIER=`printf "%0128i" 0`
APPORT_REPORT_DIR=`pwd`/reports whoopsie -f &
WHOOPSIE_PID=$!
ERRORS_URL=errors.staging.ubuntu.com ./integration-test
kill $WHOOPSIE_PID

In the past we had a few issues with the crashes moving through to the
queues and being processed by the retracers. So if it does fail, the
first thing to check would be the rabbit queues and the state of the
retracer workers. Following that, this API call will tell you what the
retracers have managed to accomplish:

https://errors.staging.ubuntu.com/api/1.0/retracers-results/?format=json

There's also the retrace.log file on the retracers themselves.