When the build engineer is out there are two rules:

  • The team will want to release
  • The build will fail

In this case there were two failures. The first was an Apple API update that caused the Fastlane components we use to fault. Easy enough to fix with an update, which I did on my day off. I did come back to our iOS builds failing due to timeout again. I noticed it’s at the same code signing spot as earlier. I think I’m going to back out the change someone made where the code isn’t signed and reapply my code signing diff.

Well, that mostly worked. It presented a different error: the framework is required to be signed. From my current understanding the signing occurs in the final phase of building an application archive and should clobber any prior signing of frameworks for the one. Apparently that assumption is now wrong under Xcode 8. Following the styling of Himotoki library, let’s try that.

While waiting on the run I continued to assert my RFC5424 parser works according to the spec, less parsing the structured data. I ran into a problem with injecting the byte order marker. I’m hoping that doesn’t become an issue, but I would really like to find a solution for that.

Hmm, builds are still failing due to the tiemout. I’m wondering what the best way to approach the build timeout issue is. I was thinking I could set the rusage variables to abort after 9.5 minutes, but the entire build takes a bit longer than that. It bails after output the copying an internal library file. This SO post on headers looks interesting. Just a discussion on header visilibility unforunately, not going into much detail sadly. Fastlane Issue #4197 discusses code signing failures due segfaults in the underlying xcodebuild processes driven by gym. We are building against iOS 10.0 for our tests and latest which resolves to 10.2 for our production like builds. Part of the issues I had earlier I believe were cause by similar problems. I wonder if dropping back to iOS 10.0 will resolve the immediate problem.

I should really know better than to use the short options for commands in build scripts. I know I don’t want to go look up what a flag does, so I’m guessing no one else will. Hopefully the sdk option to gym will select the iOS 10.0, time to verify though. Actually, after investigating our .travis.yml file it turns out we are using Xcode 8.1. I’ll update that first. Since my confidence is low and I’ve got some time before I get actionable feedback I need to figure out how to target verison 10.0 of the SDK via gym. I’m hoping it’s as easy as a simple command. Confirmed.