Bitrise makes mobile deployment a breeze, but the options they provide for automatic build triggers are very all-or-nothing. In this post, we'll go over how to easily trigger Bitrise builds, but only when we want to.
Triggering Bitrise Builds
Bitrise provides "fast, flexible, and scalable mobile CI/CD that just works." That's actually quite accurate! Creating and triggering build workflows is straightforward with Bitrise.
Out of the box, it easily integrates with your Git provider. After integration, Bitrise uses webhooks to provide the following automatic build triggers:
- Trigger via push to a specific branch (or, ANY branch)
- Trigger via pull request (can filter by target or source branch)
- Trigger via specified git tag
These are super helpful for many workflows, however our ideal trigger wasn't quite covered...
Close But No Cigar
At CompanyCam, our ideal trigger would be closest to the "Trigger via pull request" method, but we really didn't want every single PR to trigger a build (we are paying for each of these builds, after all).
First off, certainly not all PRs would require our entire pipeline to run, especially if all that changed was the README! Other smaller changes could easily be tested on our nightly builds and wouldn't require an entire dedicated build.
Secondly, filtering and triggering builds via a branch naming convention could work, but would require developers to either:
(a) have prior knowledge when creating their branch that they would later want a Bitrise build for that branch, or
(b) rename/duplicate their branch as they encountered the need for a build (to match the triggering naming convention)
Neither of these felt ideal.
We were looking for a way to enable our developers to selectively choose whether their PR would or would not have a Bitrise build associated with it, at the moment they opened the PR (or even after!)
Ad-Hoc Automation
The solution we sought was simple. We were looking for a way to add "Trigger by PR Label" functionality to connect our repository and Bitrise. How could we achieve this ad-hoc automation?
Well, more on that in a second... but first, there's a hidden gem you should know before we go further (one that we'll use shortly):
While using the Bitrise web app, when you click "Start/Schedule a Build", navigate to the Advanced tab, and scroll to the bottom, you should find this handy-dandy, copy-paste-ready cURL request for triggering a build (with the specific options you added in the form above) - Slick!
Putting Our Labels to Work
Okay, now we can actually answer "How could we achieve this ad-hoc automation?"
Enter: GitHub Actions.
Along with our copy-paste-ready cURL request, and some simple logic to check for a label with the name "Build Bitrise" (code below), we have a short and simple GitHub action that effectively acts as a "Trigger Build by PR Label" for our repository.
✨ Now, any PR with any source or target or branch name can have an associated Bitrise build simply by slapping a label on it!
Here's the entire GitHub Action we use: (with some secrets removed).
Happy Triggering!
About CompanyCam
👋 Hi, we’re CompanyCam. We create simple-to-use, visual-first communication and accountability tools for contractors.
We are almost always hiring developers (we like React and Rails a lot). Check out our careers page to learn more.
Post Script
You might have noticed, there are some extra params we added to the copy-paste-ready cURL request:
"build_params":{
"branch":"${{ github.head_ref }}",
"branch_dest": "${{ github.event.pull_request.base.ref }}",
"workflow_id":"deploy-internal",
"commit_hash":"${{ github.event.pull_request.head.sha }}",
"pull_request_id": ${{ steps.pr_number.outputs.number }}
},
These params help better identify this PR in Bitrise, and perhaps most importantly help with associating future builds from the same PR to maintain the rolling builds functionality provided by Bitrise 🎉
Credits
Cover Photo by Dan-Cristian Pădureț on Unsplash
Top comments (0)