Race condition when testing with electron

[Gozala]

Describe the bug
It appears that two (sub)packages running electron tests run into race condition. One is downloading / unzipping an Elector while other running in parallel seems to think electron is available and attempt to launch it fails.

Here is the example of such race https://travis-ci.com/github/ipfs/js-ipfs/jobs/351600109 which happens consistently on ipfs/js-ipfs#3081. As @achingbrain pointed out this probably is not happening on the master because other ipfs depends on ipfs-http-client so test do not execute in parallel.

Looking at the source

aegir/src/utils.js

Lines 172 to 184 in 4b4ce35

	exports.getElectron = async () => {
	const pkg = require('./../package.json')
	const version = pkg.devDependencies.electron.slice(1)
	const spinner = ora(`Downloading electron: ${version}`).start()
	const zipPath = await download(version)
	const electronPath = path.join(path.dirname(zipPath), getPlatformPath())
	if (!fs.existsSync(electronPath)) {
	spinner.text = 'Extracting electron to system cache'
	await extract(zipPath, { dir: path.dirname(zipPath) })
	}
	spinner.succeed('Electron ready to use')
	return electronPath
	}

I am guessing electronPath exists because first process started zip extraction but has not finished. I am not sure what would be a good solution here. Probably getElectron should recognize pending download and watch fs to be notified once electron is ready ?

[achingbrain]

That sounds like a reasonable approach, would you like to open a PR that implements this?

Perhaps it should drop a lock file in a known location which it then removes once the download is complete & the zip file expanded? If it is present, the other process could wait for the lock file to be removed before continuing with some sort of inactivity timeout.

The download location of a given electron version is stable so you should be able to do something similar to work out where to put the lock file.