Skip to content

Bitrise Overview

Jump to bottom
Clare So edited this page May 9, 2024 · 5 revisions

Overview

Bitrise is a CI/CD tool used in the Firefox and Focus iOS development. Its main usage is for the iOS developers to do some basic checks on pull requests automatically before the pull requests are merged. The release management also leverages Bitrise to release the app to the appropriate channels. Mobile Test Engineering uses Bitrise to launch various performance and crash tests on a schedule. Bitrise also reports the results, provides the logs for the pipelines and analyzes the trends.

Our Bitrise page contains the information on the status of the builds.

Screenshot from Bitrise

Many operations from this page require authentication. All internal Firefox iOS developers should have access to this page. Please contact Mobile Test Engineering for the permission.

Bitrise builds

The Bitrise CI/CD build configurations are found in bitrise.yml. The configuration file is version-controlled so we can rollback if a change is undesirable. It defines when and what is run in the builds. In addition, it specifies the build machines to be used

A build consists of steps, workflows and stages that are organized in pipelines.

  • A step defines a single build task. It can be a script or an invocation of a predefined Bitrise Step. An example step in our case is to compile the app’s source code with the appropriate parameters.
  • A workflow contains one or more steps. The steps in a workflow run in order. We can define the dependencies between different workflows. We also use a workflow to set some environment variables for use in other workflows.
  • A stage contains one or more workflows. All workflows from a stage must pass before the next stage starts: The stages run sequentially. Different workflows can be configured to run in parallel in a stage.
  • A pipeline contains one or more stages. The pipeline’s triggers are defined in bitrise.yml. See Use Cases for a selected list of those triggers.

We have been using the build machines hosted by Bitrise. The build machines are virtual environments with fresh installations of the software including specific versions of macOS, iOS simulators and Xcode. Such a clean environment reduces the chances of builds and tests failing outside of our control.

Bitrise triggers

Bitrise triggers pipelines to do basic checks on every pull request opened, to check for sanity on every push in main or release branches and to perform some regularly scheduled tasks. In addition, Bitrise keeps track of pass/fail history and timings for further inspection.

🛑 Please create branches directly from main. The triggers don’t work for pull requests from forks.

Github Events: Pull requests (PRs) and Push

One of the following actions triggers the pipeline pipeline_build_and_test:

  • A member of the Firefox iOS team opens a PR
  • A member of the Firefox iOS team approves an external contributor’s PR to build on Bitrise
    • 🛑 A PR opened by external contributors will not start a Bitrise pipeline automatically. A member of the team must approve the build on the Bitrise page to prevent abuse.
  • A PR is merged to main, release or epic branches

This Bitrise pipeline performs the following in stages in order. Each stage consists of workflows to build and run tests. Note that pre_configuration consists of a workflow that determines if Firefox or Focus related workflows are run in later stages.

  • pre_configuration
    • Determine if the Firefox or Focus related workflows are run
  • build_applications
    • For Firefox:
      • Build Firefox
      • Run unit tests
      • Run Swiftlint
      • Get number of warnings
    • For Focus:
      • Build Focus
  • run_tests
    • For Firefox:
      • Runs all smoke tests in 4 workflows running in parallel
    • For Focus:
      • Run all unit tests and smoke tests in 3 workflows running in parallel

Here is an example of a successful Bitrise pipeline.

Screenshot of a Bitrise pipeline

The test results are reported back to the pull request from Github. You can find the test results near the bottom of the Github pull request.

Screenshot of Bitrise reports to Github

A green ✅ pipeline means that there is no obvious errors in the change and the PR is ready to be merged. A red ❌ pipeline may block the PR to be merged to main. For tips on diagnosing issues from a pipeline, please see “Retry Bitrise Pipelines”.

Scheduled Workflows

We have some regularly scheduled builds running on Bitrise for some repetitive tasks. Here are some of those workflows:

  • L10nBuild: Grab a set of predefined screenshots of the Firefox iOS app for different locales.
  • Archive_and_Run_Robo_Test: Invoke Google Firebase Test Labs to run a Robo test. Robo test is used to crawl the app randomly to find bugs and crashes.
  • Firebase_Performance_Test: Invoke Google Firebase Test Labs to run performance tests on multiple physical iOS devices hosted by Google.
  • Bitrise_Performance_Test: Measure Firefox iOS app’s performance with a set of predefined databases loaded.
  • focus_SPM_Beta, focus_SPM_Nightly, focus_release: Release Focus to the different channels.
  • SPM_Deploy_Prod_Beta, SPM_Deploy_Beta_Only, SPM_Nightly_Beta_Only: Release Firefox to the different channels.

These workflows could also be triggered manually from the Bitrise page.

Screenshot of "Start/schedule build" button from Bitrise page

Bitrise Insights

Bitrise Insights reports the trends of the pipelines such as build time, build count, failure rate, duration and usage.

Screenshot of Bitrise Insights

References

Clone this wiki locally