Technical post…
Fastlane is a project to automate a number of tasks for getting an Android or iOS app published. One of the tasks I was working with was getting a report of the code coverage – how much code has unit tests. I’ve been using Fastlane for a while although I’m not an expert at it nor the Ruby language.
I found out Fastlane provides tools to use the Swift language instead of Ruby. So I gave it a whirl and things were going great, until it came time for code coverage. Slather, the tool which performs the code coverage reporting, was having a tough time finding the binary. There’s a parameter you can specify which points it right to the binary. It’s a string – a plain old file path. Nothing exciting. The problem was the Swift compiler was not happy seeing a string when it expected a Boolean. A Boolean? How did that get in there? In the Ruby version of the script, everything works fine with a string.
It turns out Ruby isn’t strictly typed like Swift. So string or Boolean, Ruby is happy, Swift not so much. I figure this should be an easy change. It was. I updated Fastlane.swift and it worked. But each time I ran Fastlane, it said there was an update and would prompt with a yes/no question. This isn’t going to work in an automation script on a build server. I found a command line option to disable the question, but I realized this wasn’t a long term solution.
I posted an issue up on the Fastlane repo. Then I posted up what I thought was the solution (the fix to the Fastlane.swift file). But I learned that file is generated from Ruby code. I found the Ruby code and updated it. That worked great, but then had to update the code to handle the Boolean values (true/false) for those who update Fastlane and had set their scripts to use true/false. So I got that to go and included some unit tests. It was a bit more work than I expected for a simple “bool” to “string” change.
I just learned today the pull request was approved. The code is in master and slated for the next release.