Cross-platform – Bitrise

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.
1. 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.
2. 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.
3. Click the Fastlane Step to fill out the required fields.
4. Add your lane in the fastlane lane input.
5. 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 ./here/is/my.
6. The Should update fastlane gem before run? option will be skipped if you have a Gemfile in the work_dir directory.
  
  If you don’t have a Gemfile and this option is enabled, then the Step tries to use and run the latest fastlane version.
7. Set the Enable verbose logging? to yes if you wish to get more detailed logs on your failed builds.
8. 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):
  
  Pods - Podfile.lock
  
  Carthage - Cartfile.resolved
  
  Android dependencies
That’s it! Start a build so that Bitrise can run your lane.
Configuring fastlane match for Bitrise
If you want to use fastlane match in your bitrise.io build, you only have to do three things:
1. Make sure that a single SSH key can be used to git clone both your main repository (the one you register on bitrise.io) and the match repository.
2. Add an Environment Variable MATCH_PASSWORD to specify the passphrase you 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.
3. Make sure to use match’s readonly mode, or else match will 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 in your Fastfile or fastlane config: 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
Issue:

My Flutter builds take too long on Bitrise.
Possible solutions:

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:
Why does my builds take longer on Bitrise than on my machine?

Optimize your build times

Quick and dirty guide to Flutter on Bitrise
If the above articles don't help, try reducing the build time by integrating the firestore-ios-sdk-frameworks repository to your ios/Podfile inside your Flutter project with a one-liner command as mentioned in this GitHub issue:
[Update] Cloud Firestore Xcode Build Times #2751.
error: Could not resolve package dependencies in Flutter
Issue:

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
```
Possible solutions:
Close your workspace in Xcode.

Open the .xcodeproj file INSTEAD of the .xcworkspace file (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.

Open the .xcworkspace again and it should work!
Build using BrowserStack fails with UnknownHostError
Issue:

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
```
Possible Solutions:

To fix this issue, you should change the default DNS server to Google’s DNS server, 8.8.8.8. This way, Java can use it to resolve the host every time.

To change the DNS server to 8.8.8.8, include the following in a Script Step:
```
networksetup -setdnsservers Ethernet 8.8.8.8
```
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:
```
scutil --dns
```
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 8.8.8.8
            networksetup -getdnsservers Ethernet
            scutil --dns
```
Flutter Test Step freezes on "Waiting for another flutter command to release the startup lock..."
Issue:

The Flutter Test Step freezes or hangs with the following error:
```
Waiting for another flutter command to release the startup lock...
```
Possible solutions:

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:
Deleting your cache

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.
Checking resources and import issues

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.

Connect to Apple services

Issue:

Possible solutions:

Issue:

Possible solutions:

Issue:

Possible Solutions:

Issue:

Possible solutions:

Deleting your cache

Checking resources and import issues