How to expose Fastlane lane + options when doing a manual build?

Question & Answer
1

Hey Bitrise team!

For each of our apps we have a bunch of lanes:

  • internal --> build an internal we test internally, it has a bunch of stuff we don’t want to push to prod users.
  • prod --> build a release candidate.

Additionally we use a Fastlane option to deploy an internal or prod build, respectively to Crashlytics Beta or iTunes Connect / Google Play Alpha.

Thus, building our lanes with Fastlane look like this for iOS and Android:

  • fastlane internal deploy:false
  • fastlane prod deploy:true
  • fastlane internal deploy:true
  • fastlane prod deploy:true

I could go with one workflow per combination but was wondering if there is a way to expose the lane and options so I keep one workflow and it’s easy to kick a manual build with any of those lane and deploy combinations?

Thanks!

2

Hi,

Thanks for asking the question here! :slight_smile:

I’d suggest you to do this, to have a Bitrise workflow for every “combination” you want to run. That way you can simply select which one to run by selecting the Workflow, and additionally you can automate these, e.g. to run “internal” for changes on “develop”, and “prod” on the “master” branch (or anything like that).

For more info about automatic workflow selection for triggers please see: Using the Trigger Map to trigger builds - Bitrise Docs

One more note: you can create one workflow where you describe how you call fastlane, and then just “reference” this common workflow from the other workflows, so that you don’t have to define the same workflow multiple times and you don’t have to maintain them separately either. You can find an example here: https://github.com/bitrise-docker/bitrise-base/blob/master/bitrise.yml#L28

  rebuild-pinned:
    before_run:
    - _pinned_envs
    after_run:
    - _rebuild

  rebuild-alpha:
    before_run:
    - _alpha_envs
    after_run:
    - _rebuild

TL;DR; both rebuild-pinned and rebuild-alpha does the same thing, running the _rebuild workflow, the difference is the environment variables set by _pinned_envs vs _alpha_envs. You can of course specify the envs: directly on these workflows, in this case we used a separate workflow (_pinned_envs and _alpha_envs) because we did use the same env combinations multiple times, through multiple workflows.

If you have any questions, just let us know!

Happy Building! :wink:

3

That works - thanks Viktor.

1 Like
4

Any time :wink:

Happy Building!