If you weren’t already aware, I’m already a big fan of bitrise – and when I heard they were adding support for Flutter, I gained even more love for the product. Naturally I wanted to take this for a spin – so I decided to setup Bitrise CI with my Voice flutter project. Let’s take a quick look at how we can setup our Flutter projects in Bitrise CI and what is available with the workflow editor.
Setting up the project requires minimal manual steps from your side – Bitrise automates as much of the process that is possible. After hitting the ‘Add app’ button you’ll be presented with the options to choose the bitrise account which the project is linked to, along with whether or not the project should be publicly available. For the purpose of this example I set the project to public – you can explore the entire project here.
Now that we’ve setup the first step of our bitrise project, we need to assign a repository to it so that bitrise can build our desired project. At this point you’ll notice that you organisations and repositories are listed – select the project that you wish to assign. You’ll notice here that the available repositories will depend on the privacy option that you selected in the previous step. At this point, if you selected a Public app privacy then you will not be able to select a Private repository.
Now that we have a chosen app for our Bitrise project, we need to go ahead and select the branch which is to be built. For my Bitrise projects I usually select master at this point, just because that is the main branch of my projects – if you have some different workflow then enter the name of the branch that makes the most sense for you.
After we hit next, Bitrise will start to validate our repository. This just performs checks to ensure that the project is of a supported format – it’ll take a few seconds and then you’ll be good to continue onto the next step.
Once the repository has been validated, you’ll be able to change any configurations for the project. You’ll notice here that the project has been recognised as a Flutter project. At this point we’re given the option to configure whether or not we want to run the tests which are found within our project – if you’ve got tests (or even if not) you’re going to want to have this selected as yes.
When it comes to the configuration of the project at this stage, there might not actually be anything that you want to change. The selected defaults were enough to satisfy the requirements of my project – this may differ when it comes to your setup though!
Finally, we’re going to want to setup a webhook if we want to make use of build triggers within our project. If you don’t register one at this point then you can do so later, it just means you won’t have triggered builds until you have done so.
And at that point, our project is all setup and ready to go! Bitrise will have automatically kicked off a build for you at this point – so you can head on over to your project dashboard to watch the status of it.
Now that the project is setup, let’s jump into the default workflow that has been configured for our project. Now at this point I’m not going to run through how we can customise this, more just what Bitrise will provide us out of the box.
Within the workflow editor you’ll see these three Flutter related steps – these are what are going to handle the Flutter related parts of our project. To begin with we see the Flutter Install step – this takes the official Flutter repository and clones it so that the Flutter SDK can be setup. This will be required for every workflow and currently it looks like Bitrise is downloading it on every build – hopefully in future there will be some form of caching in place to speed up this process 🙂
Secondly we have Flutter Analyze – if you’re not familiar with this tool then it’s essentially a code analyser that can be used to find issues in your Dart code. If any issues are found here then they will be printed within the Bitrise build logs – what would be handy here is to make use of these with another build step to automate PR reviews for errors here. Currently though, you’ll just have to check the logs for these details.
Finally, we have the Flutter Test step. This step will be used to run any tests that you have in your project – this will depict whether or not your build fails / passes. If set to fail your builds then any Pull Requests that are opened will be used to display the status of the build. Here I opened to Pull Requests for Voice, each with a different test status. You can see each status is reflected within the Pull Request title:
This post aimed to be a short look into how little work is required to add CI with Bitrise to your Flutter project. With only a number of steps, you can have a fully automated CI setup for your Flutter project – complete with tests running for Pull Request validation!
If you’re looking at setting up Bitrise for your Flutter project, feel free to reach out with any questions or thoughts that you may have on the topic!