Integrating fastlane to Bitrise
You can run your fastlane lane on Bitrise with the same commands you would use locally. Bitrise’s automated Steps provide extra functionality to your lane and speed up your builds.
Here is how you can benefit from integrating fastlane into Bitrise.
Our Fastlane Match Step takes care of code signing your project by cloning your private certificate/profile repository and registering the certificates and profiles in the keychain.
On Bitrise, you can run separate lanes for separate branches automatically. For example, you can run a lane for every code push onto the main branch to update screenshots and metadata on the App Store and to release the distribution version. You can run a separate lane for the develop branch to run your automated tests and deploy your test releases for your QA team. You can simply clone the Workflow multiple times, specify the lane to run for the given Workflow in a Workflow Specific Environment Variable, and use automatic triggers to define which Workflow should be selected for this branch / tag / pull request.
Running fastlane on Bitrise is as simple as adding one Step to your Workflow and setting some options. Let’s see how!
Connect to Apple services
Do not forget to connect to Apple services if you use this Step in your Workflow.
Add the Fastlane Step to your Workflow.
Make sure it is inserted right after the Git Clone Step. Since fastlane is pre-installed on all Bitrise’s virtual machines, the Fastlane Step ensures that you can always use the required fastlane version.
To code sign your project, you have a couple of options to choose from:
Add one of Bitrise’s code signing Steps to your Workflow, such as: Certificate and profile installer, iOS Auto Provision, and Fastlane Match. See our guides on Code Signing for more information.
Alternatively, use fastlane match inside your fastlane lane instead of a code signing Step. Make sure you either use the Fastlane Match Step or set up fastlane match in your lane but don’t try to do both.
Click the Fastlane Step to fill out the required fields.
Add your lane in the fastlane lane input.
Use Working directory field if the fastlane directory is not in your repository’s root.
The working directory should be the parent directory of your
Fastfile’s directory. For example, if the Fastfile path is
./here/is/my/fastlane/Fastfile, then the
Fastfile’s directory is
./here/is/my/fastlane, so the Working Directory should be
The Should update fastlane gem before run? option will be skipped if you have a
If you don’t have a
Gemfileand this option is enabled, then the Step tries to use and run the latest fastlane version.
Set the Enable verbose logging? to yes if you wish to get more detailed logs on your failed builds.
If the Enable collecting files to be included in build cache is set to yes, the Step adds the following cache items (if they exist):
That’s it! Start a build so that Bitrise can run your lane.
Configuring fastlane match for Bitrise
Make sure that a single SSH key can be used to
git cloneboth your main repository (the one you register on bitrise.io) and the
Add an Environment Variable
MATCH_PASSWORDto specify the
passphraseyou used for
match. On bitrise.io you should add this as a Secret Environment Variable in the Workflow Editor. Make sure to disable the Replace variables in input? option of the environment variable to avoid causing issues when the value includes the
$(dollar) sign, which is used for environment variable expansion.
Make sure to use
readonlymode, or else
matchwill try to connect to the Apple Developer Portal, which requires further authorization (providing additional username and password for Apple Dev Portal login)!
If you use
match(app_identifier: "my.domain", type: "appstore", readonly: true).
If you use it as a command line tool:
match development --readonly.
That’s all, you can now enjoy the utility of
match, automated with bitrise.io .
Flutter builds take too long on Bitrise
Compiling the Firestore iOS SDK in a CI environment might take longer due to lengthy C++ code dependencies. To speed up your build, we recommend you check out our articles on how to optimize build times:
If the above articles don't help, try reducing the build time by integrating the firestore-ios-sdk-frameworks repository to your
ios/Podfileinside your Flutter project with a one-liner command as mentioned in this GitHub issue:
error: Could not resolve package dependencies in Flutter
When adding a dependency with Swift Package Manager in Xcode for a Flutter project, your build fails with this error message:
xcodebuild: error: Could not resolve package dependencies: Packages are not supported when using legacy build locations, but the current project has them enabled. Command: /usr/bin/xcodebuild -list
Close your workspace in Xcode.
.xcodeprojfile INSTEAD of the
.xcworkspacefile (most likely /yourApp/ios/Runner.xcodeproj).
When the project is open, in the Xcode menu bar click File -> Project Settings -> Advanced.
Change the option from LEGACY to XCODE DEFAULT.
.xcworkspaceagain and it should work!
Build using BrowserStack fails with UnknownHostError
When building your app using BrowserStack your build fails with an UnknownHostException error:
java.net.UnknownHostException: prd-20-04-usc1b-220309133144-sny9nhmtmjrqxdjxrupapg: prd-20-04-usc1b-2203091222144-snyasdnhmtmjrqxdjxrupapg: Name or service not known
To fix this issue, you should change the default DNS server to Google’s DNS server,
220.127.116.11. This way, Java can use it to resolve the host every time.
To change the DNS server to 18.104.22.168, include the following in a Script Step:
networksetup -setdnsservers Ethernet 22.214.171.124
You should clear your DNS cache to ensure your old DNS address is no longer in use. To do so, add:
networksetup -getdnsservers Ethernet
Finally, to verify that the change was successful, you can print the current DNS server with the following script:
Add the Script Step to your Workflow before any Steps that use BrowserStack.
Combining the information from above, the Script Step should look like this:
steps: - script@1: inputs: - content: |- #!/usr/bin/env bash # fail if any commands fails set -e # make pipelines' return status equal the last command to exit with a non-zero status, or zero if all commands exit successfully set -o pipefail # debug log set -x networksetup -setdnsservers Ethernet 126.96.36.199 networksetup -getdnsservers Ethernet scutil --dns
Flutter Test Step freezes on "Waiting for another flutter command to release the startup lock..."
The Flutter Test Step freezes or hangs with the following error:
Waiting for another flutter command to release the startup lock...
Unit tests consist of three phases:
Arrange - In this phase you set up test values and bring in dependencies and mock classes as needed.
Act - During this phase, you take whatever action you're trying to test. For example, passing a value to a method and saving its output to a variable.
Assert - Finally, you check to see if the result from the Act phase matches your expectations. If it doesn't, the test fails.
As long as your test fails in the Assert phase, Flutter will give you an error message regarding the problem. If something goes wrong in the Arrange or Act phases, Flutter will frequently freeze with the startup lock error.
The most frequent cause of this error is misconfigured dependencies within the unit test. Here are some possible fixes:
If you're using the Bitrise.io Cache:Pull and Bitrise.io Cache:Push Steps, there's a chance that you have an outdated dependency cached that's causing the problem.
In your app, click on the Settings tab.
Scroll to the bottom of the page.
Use the option provided to clear your cache.
Make sure your tests aren't dependent on external resources: Your tests should never be reliant on external resources such as API's, data providers, cloud storage, or other external services.
Make sure your dependencies are being imported correctly. It's possible that one of your tests is malformed and isn't importing dependencies properly.
If everything above looks good, you need to manually review each of your tests. If the problem started recently, start by checking your newest tests. Otherwise consider temporarily removing half of your tests to see if the issue resolves. Keep narrowing the set until you find the test causing the issue.
- Integrating fastlane to Bitrise
- Configuring fastlane match for Bitrise
- Flutter builds take too long on Bitrise
- error: Could not resolve package dependencies in Flutter
- Build using BrowserStack fails with UnknownHostError
- Flutter Test Step freezes on "Waiting for another flutter command to release the startup lock..."