> email to zotero-dev+unsubscribe@googlegroups.com.
I didn't change much in the end, but here is the logic of the fix. The resetDB() invocations themselves are just the ones in the existing fixtures Juris-M inherits from Zotero, e.g.:The reset calls Zotero.reinit():Zotero.reinit() calls Zotero.init():After hopping through some internal functions, Zotero.init() ultimately calls Zotero.updateSchema():My draggy operations were in the schema update, and they were running in full every time the DB was reconstructed. Masking them or subbing in skeleton data when the skipBundledFiles option was turned on was the fix. I did that in three places (but looking at the code now, I see that it should only happen in two -- the _populateJurisdictions function should just be smartened up, rather than masked at execution):In addition, I needed to extend the timeout applied to callbacks. That wasn't relevant to the resetDB issue, but Juris-M takes more time to complete some operations, and that was producing erratic failures in Travis. The main change for that was here (increasing 10000 Zotero timeout to 20000):With the adjustments, the Juris-M tests complete in about 28 minutes of Travis run-time. The ceiling of free accounts is around 50 minutes, so this will be kind of pushing it was the Zotero test suite grows over time, but for the present all is well.
I didn't know about CircleCI. That's good to know, and thanks!The Zotero tests are run as two concurrent instances of the full suite, one against FF 54.0, and another against 52.0.3. If Travis allows four streams, that should open some more margin against the future. Again very good to know.
The time taken for builds isn't a problem for me -- if anything, it forces me to think more deliberately about changes, so I'm all smiles for now.
Travis is pushing the zipped client bundle to S3 now, as per design. I have a little work ahead today on ./build.sh script in my fork of zotero-standalone-build, then some changes to the Juris-M website, and we should be rolling here.