Same code different build output on Windows

Environments Windows
1

I have two branches with exactly the same code and the tests for one fail, while on the other one they pass.
The job that fails is 174.2 and the job that passes is 168.2
Both are on Windows and have exactly the same yaml config with exactly the same code.
The error log of the failing job is this:

Client initialization failed after 10 attempts: RuntimeError Client initialization failed after 10 attempts: 
[0] Error: unknown error: Chrome failed to start: exited normally
[0] (unknown error: DevToolsActivePort file doesn't exist)
[0] (The process started from chrome location C:\Users\travis\build\intacct-thyme\thyme-tracker\node_modules\spectron\lib\launcher.bat is no longer running, so ChromeDriver is assuming that Chrome has crashed.)
[0] (Driver info: chromedriver=78.0.3905.1 (c7cce564a78f7c44042856c33e2f3dab0bc4307d-refs/heads/master@{[#703739](https://support.travis-ci.com/hc/requests/703739)}),platform=Windows NT 10.0.17763 x86_64)
[0] at new RuntimeError (node_modules\webdriverio\build\lib\utils\ErrorHandler.js:143:12)
[0] at Request._callback (node_modules\webdriverio\build\lib\utils\RequestHandler.js:318:39)
[0] at Request.self.callback (node_modules\request\request.js:185:22)
[0] at Request.EventEmitter.emit (domain.js:475:20)
[0] at Request.<anonymous> (node_modules\request\request.js:1161:10)
[0] at Request.EventEmitter.emit (domain.js:475:20)
[0] at IncomingMessage.<anonymous> (node_modules\request\request.js:1083:12)
[0] at IncomingMessage.EventEmitter.emit (domain.js:475:20)
[0] at endReadableNT (_stream_readable.js:1184:12)
[0] at processTicksAndRejections (internal/process/task_queues.js:80:21) .

The problem started when I added 2 commits, so I reverted both of them and run the tests for each revert to see if the problem was my code, but I reached the point where both jobs had identical code and it still failed.
Any idea why this may be happening? Was there any change to the windows environment lately?

Note: I cancelled both jobs because they didn’t finish themselves.

Thanks in advance

2

In the failing job, you see this:

prebuild-install http 404 https://github.com/atom/node-keytar/releases/download/v4.13.0/keytar-v4.13.0-electron-v75-win32-x64.tar.gz

This URL returns 404 from my machine:

$ curl -IL https://github.com/atom/node-keytar/releases/download/v4.13.0/keytar-v4.13.0-electron-v75-win32-x64.tar.gz
HTTP/1.1 404 Not Found
Server: GitHub.com
Date: Tue, 11 Feb 2020 14:05:31 GMT
Content-Type: text/plain; charset=utf-8
Status: 404 Not Found
Vary: X-PJAX
Cache-Control: no-cache
Set-Cookie: logged_in=no; domain=.github.com; path=/; expires=Thu, 11 Feb 2021 14:05:31 -0000; secure; HttpOnly
Set-Cookie: _gh_sess=MW0wdE1kc0tQT2c5K1VmbnQvdWhydnozd1R3bGtWSUUxZ1BobkxYVHJ5Q0hyRGdidWVQWXdFczhycWRHMU9TM0d2RGlsenpzZm9WazJURkhPTE1PSFNPTzgzV3poMnZoOCtNRXc5cUVOdDZoYXNzRG05VWF0SmRYT2hBQkFuSW9XV3hpNk5sTzJ2MmQxVEJMSzc2amZBPT0tLUFBQTJDNGk5UEZvT3I0S1VwRGZHUHc9PQ%3D%3D--b4ee251f68d5ee0caa264ab45b6292cdd547ff1e; path=/; secure; HttpOnly
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
X-Frame-Options: deny
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Expect-CT: max-age=2592000, report-uri="https://api.github.com/_private/browser/errors"
Content-Security-Policy: default-src 'none'; base-uri 'self'; connect-src 'self'; form-action 'self'; img-src 'self' data:; script-src 'self'; style-src 'unsafe-inline'
Vary: Accept-Encoding, Accept
X-GitHub-Request-Id: F5EA:1CBF:573B87:8C4060:5E42B4AB

This probably explains why your build is now (?) failing. Please double check you have the right URL.

There is no v75 in https://github.com/atom/node-keytar/releases/tag/v4.13.0 binaries.

3

Actually, that 404 is present in both.

We appear to have updated the Windows image; the passing build found a cache:

fetching diagnostics-fixes/cache--windows-1803-containers-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--node-12.14.0.tgz
found cache

and the failing one did not:

fetching diagnostics-fixes/cache--windows-1809-containers-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--node-12.14.0.tgz
fetching diagnostics-fixes/cache-windows-1809-containers-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--node-12.14.0.tgz
fetching diagnostics-fixes/cache--node-12.14.0.tgz
fetching development/cache--windows-1809-containers-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--node-12.14.0.tgz
fetching development/cache-windows-1809-containers-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--node-12.14.0.tgz
fetching development/cache--node-12.14.0.tgz
could not download cache

Could that explain the difference?

4

It fails in both and the "postinstall": "electron-builder install-app-deps" builds it for the app.

Regarding the cached windows version, I see that the failing build sais: “could not download cache” for 1809 version, while the passing one downloads the 1803 version. Since you updated the windows version, that means we can now choose versions? I’ve no idea why it fails on 1809, I’ve got the same on my local and it passes

5

We do not provide the ability to select Windows images at this time.

6

Your build logic should handle it correctly whether a cache is present or not because a cache, including Travis cache, is treated as volatile. E.g. Travis cache expires automatically, and any changes to the environment that a job runs in invalidate it.

So if your build works with cache and fails without, that’s a clear problem with the build logic.

7

Ok, thank you!