Open JohnSundell opened 7 years ago
Most of the time when I was getting strange errors in different CIs it was regarding timeouts. We're using free plans, so the bandwidth etc. is relatively slow. Marathon test suite is heavy, so I wouldn't be surprised if it will turn out to be timeout errors.
Regarding buddybuild error. Maybe extracting try? folder.subfolder(named: "Packages").file(named: "Files").read()
to a let
can will help?
Feels like Swift 3.2 introduced new problem. Take a look at this integration .
I've faced this issue locally as well when I was running tests. It's stuck on testAddingAndRemovingRemotePackage
or testAddingLocalPackage
.
@cojoj Fixed that issue here: https://github.com/JohnSundell/Marathon/pull/104
Our CI can sometimes exhibit some flaky behavior in that it'll fail for no good reason, and a retrigger solves the problem. Let's investigate what's going wrong (maybe it's a caching thing, or some state that isn't properly cleaned up, or some race condition?) and fix it!
Interestingly, the flakiness is different on BuddyBuild vs Travis.
Travis
Here's what a failed build log usually looks like on Travis:
As you can see above, it just exits with
code 1
, no additional debug information seems to be found 😢 It also seems like it stops on different test cases every time this happens, so don't think it's a problem with a single test case. Perhaps a timeout issue?BuddyBuild
On BuddyBuild things are a lot more consistent, and should be easier to fix. It always fails on this test case:
Rebuilding without cache seems to fix the problem. Perhaps some cleanup not being made?