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. -- Mailing list: https://launchpad.net/~canonical-ci-engineering Post to : [email protected] Unsubscribe : https://launchpad.net/~canonical-ci-engineering More help : https://help.launchpad.net/ListHelp
