OK, we love Bitrise, so we’re using it more and more. We have very similar workflows from one app to the next and right now I am manually creating workflows for develop, feature and master branches for each new app, copying and pasting like a boss from existing workflows. There’s gotta be a better way!
What is best practice for re-using flows, or at least using an existing flow as the template for a new flow in a new app?
Great question!
There are many ways to do this, I’d say the most common one is probably to store the bitrise.yml in your repository. You can also store it in a separate repository and use that as a submodule for example in your main repo, just make sure that the same SSH key can be used for all the repos during the build.
For storing the bitrise.yml in your repository, you can find a guide here: http://devcenter.bitrise.io/tips-and-tricks/use-bitrise-yml-from-repository/
Right now the main disadvantage of this approach is the lack of UI editor, but that will soon change - we’re working on a complete revision of the workflow editor and it will be open source, and you will be able to run it locally on your Mac too, editing any bitrise.yml from your Mac directly. Related #dev:work-in-progress discussion: Workflow Editor “v2” (Open Source & Offline Workflow Editor)
The first beta is scheduled for this week, if you’re interested make sure to subscribe to/watch this discussion.
If anyone have any additional solution for this, please share it with us here!
Hi Viktor
OK, I finally found some time to look at this solution and it’s pretty amazing. I can now build my apps using a bitrise.yml file stored in the repo of the app.
I would, however, prefer to use a single yml file for multiple apps, and the problem here is that there are several parts of the yml file which are app-specific, eg the name of the solution, the name of the Android manifest file etc.
I can’t think of any ways to do this - basically I need my single yml file to have access to app-specific variables. Is there something that pops to mind as a solution for this?
Adrian
No problem at all!
If you follow the Managing an app's bitrise.yml file - Bitrise Docs guide then you basically have two build configs, one on bitrise.io and one in your repository (bitrise.yml).
The trick to do what you described is: make the bitrise.yml generic, if it really can be used for multiple projects, and define the parameters in the “wrapper” config you have on bitrise.io.
We usually mark parameters which we expect to be defined outside of the build config by adding it to App Env Vars or Workflow env vars like this:
envs:
- A_REQUIRED_PARAM: $A_REQUIRED_PARAM
If you want to run this locally, then you can specify A_REQUIRED_PARAM either in the terminal / command line as an env var before you’d run bitrise run ... (e.g. export A_REQUIRED_PARAM=my-value) or add to the .bitrise.secrets.yml and specify it there.
Now the trick: in your bitrise.yml highlight these parameters as env vars (not required, but it makes your config way easier to maintain long term), and then define the env vars on bitrise.io, either as App Env Vars of Workflow env vars (depends on whether you want to use the same value for every build, or just for builds with a specific workflow).
This way you will have a generic build config in your repo, and the project specific parameters (e.g. the name/path of the project file or workspace file) on bitrise.io.
Alternatively you can use a “secrets” / “inventory” file too, and instead of bitrise run "${BITRISE_TRIGGERED_WORKFLOW_ID}" you could pass in the “secrets/inventory” file path too: bitrise run "${BITRISE_TRIGGERED_WORKFLOW_ID}" --inventory ./app-specific-envs.yml
The format of the Secrets / Inventory env var file is:
envs:
- SECRET_ENV_ONE: first secret value
- SECRET_ENV_TWO: second secret value
More info about the secrets / inventory file: Managing Secrets locally - Bitrise Docs
The only issue with this solution is that right now the Bitrise CLI only supports one Secrets file per bitrise run, so if you want to run the build locally you might have to define real secrets manually, or do an environment wrap, e.g. using the Bitrise CLI envman util like: ~/.bitrise/tools/envman --path ./.bitrise.secrets.yml run bitrise run WORKFLOW-TO-RUN --inventory ./app-specific-envs.yml
Ok, thanks, that makes sense.
So assuming I can make this work, then I will need multiple workflows accessing the same yml file, so this file cannot be part of the repository containing the code actually being built at the time. I would either need to pull it from a separate repo (preferable in my case) or use a Github Gist as suggested in the docs.
If I add an extra git clone step to clone the repo with the bitrise.yml file in it, will the build flow automatically know to use that bitrise.yml file, or must I specify it somewhere?
Please don’t do that, use a Script step instead and git clone the config repo there. More info about why you should not use the Git Clone step for any other repo, only for the main one can be found at: Can a bitrise "build" be triggered from more than one repository? - #4 by viktorbenei - or, alternatively, add the second repo as a submodule to the main repo, that will be handled automatically by the Git Clone step.
Other than that, the same thing applies for this solution what’s described at Managing an app's bitrise.yml file - Bitrise Docs
Define a “wrapper” build config on bitrise.io, which defines how and from where your bitrise.yml will be retrieved.
So, it doesn’t matter where you store the “build config bitrise.yml”, you can store it anywhere, just make sure that it’s downloaded/available before you’d run bitrise run "${BITRISE_TRIGGERED_WORKFLOW_ID}" on it.
One more thing, the simple bitrise run "${BITRISE_TRIGGERED_WORKFLOW_ID}" call only only works if you download/make the bitrise.yml available at the root of the repository (technically it have to be at the “current working directory”, which is by default the root of the repository, but can be changed with e.g. the Change Working Directory … step). You’re of course free to download it anywhere else, in that case you just have to specify where it’s located with the --config flag:
bitrise run --config /path/to/bitrise.yml "${BITRISE_TRIGGERED_WORKFLOW_ID}"
Any updates on this? I was actually under the impression that saved workflows could be referenced from other apps.
@josonodes the question itself was how you can replicate workflows between apps, which IMO was answered (you can copy paste the YML).
If you’d like to have some kind of sharing feature please create a #feature-request with as much details as possible. E.g. should individual workflows be shared, or just a globally shared config, etc.
Couple of existing related #feature-request - if one of these would cover what you want just vote there, and feel free to leave a comment:
2nd option is what we need, voted there. Thanks!