CONFIG.executableName depends on the ATOM_RELEASE_VERSION env variable
to work correctly on nightly releases.
Since this env variable is not being set for the testing steps, the
nightly release builds contain a wrong executableName on the testing
step, which causes a failure when trying to find the Atom executable.
This commit fixes that by stop using the executableName from the test
step, like it's done on other platforms.
With this PR Atom uses a custom version of `electron-winstaller` named
`@atom/electron-winstaller` which contains a custom version of `Squirrel.Windows`
built from https://github.com/Squirrel/Squirrel.Windows/pull/149
This should fix the issues when upgrading from e.g nightly-9 to
nightly-10
We've recently updated to electron-winstaller@3.0.4, which includes a
new version of Squirrel.Windows with the following fix:
https://github.com/anaisbetts/NuGet/pull/1
Thanks to that fix we don't need anymore to disable delta nuget
updaters, since that won't fail anymore.
This is to prevent reusing the node_modules folder when there are
changes in the build system, which can affect the npm install step (like
upgrading the Node.js version).
This ensures that every test suite does not clutter subsequent ones. It
will also prevent altering the user's `~/.atom` directory when running
tests locally.
In these tests, we create a temporary `ATOM_HOME` to avoid cluttering
the user's real `~/.atom` folder.
Adding a symlink to the real `compile-cache` was introduced to speed up
main process tests, so that the transpilation cache could be reused.
Unfortunately, when the real `~/.atom` folder did not exist (such as on
a pristine environment on CI), it would confuse Atom, which would think
that it didn't need to re-create a `compile-cache` folder again, but
wouldn't be able to write to it because the symlink pointed to a
non-existant directory.
Main process tests were overhauled and made faster recently, so we can
safely remove this performance optimization.
For some reason, one main process test fails when run in a different
container than the one in which Atom was built. These tests are pretty
quick, so their impact on parallelism should be negligible.
