Here are a couple of tricks to share and store a specific workflow among multiple apps instead of building your workflow from scratch every time you add an app to Bitrise.
Using the bitrise.yml tab ⚓
Do you have a workflow that you want to “reuse” multiple times when you onboard new apps on Bitrise? An easy way to do so is using the
bitrise.yml tab in your Workflow Editor and simply copy/paste the reusable yml in your new app.
- Find the app whose workflow you want to reuse in another app on your Dashboard.
- Click the Workflow Editor of the app and find the
- Copy the yml of the reusable app from the
Paste the yml into the new app’s
- Start a build.
Please note that the newly added apps have the latest config in this case, but the previously added apps have to be updated manually if needed.
Storing bitrise.yml in the project’s repository ⚓
If you prefer, you can store the
bitrise.yml in your project’s git repository instead of uploading it to Bitrise. This is similar to the previously mentioned method but with a bonus: you can track changes using your own source control system.
Storing bitrise.yml and your projects in separate repositories ⚓
If you store your projects in a repository (repo A) and your .yml files in another repository (repo B), you can easily track changes made to the .yml files in repo B without creating extra noise in the project’s repo.
Let’s tie in Bitrise to run a specific workflow!
You have to set up a simple workflow on Bitrise which contains a
Git Clone Repository Step and two
Script Steps. The
Git Clone Repository Step clones your project’s repo (repo A), the first
Script Step clones the yml repository (from repo B), and the second
Script Step starts running the workflow specified in your yml. You can start a build manually on Bitrise or by any code push if you have set up a webhook on Bitrise.
Storing bitrise.yml in a mono repository with other project’s bitrise.yml ⚓
You might store a lot of projects (along with their own .yml files) in a single git repository (called mono repo) for easier app accessibility & management. You might prefer configuring and testing your project’s
bitrise.yml locally as opposed to testing it on virtual machines. Then you push your changes back to git project repo where changes tracked and accessible for all project members.
Now let’s tie in Bitrise and run a specific project’s
bitrise.yml directly from your git repo!
Irrespective of keeping only one project and a
bitrise.yml or more in one folder, here is what you can do:
You can use a simple workflow in Bitrise that contains only two steps:
Git Clone RepositoryStep
ScriptStep (or optionally the
Bitrise Start BuildStep)
We’re recruiting this workflow to perform 2 things: clone your git repo and start running a specific yml out of all the other projects that you store in your repo. Once the
Git Clone Repository Step has cloned your git repository, the
Script Step starts running (
bitrise run) one of your project’s
bitrise.yml or a specific workflow within that .yml file! If you have set up a webhook on Bitrise for your code hosting service, then you will be able to view your completed build’s artifacts in the
APPS & ARTIFACTS tab, once code has been pushed to git repo.