Overriding env of previous workflow/reading env of next workflow

Question & Answer
, , ,
1

Hi,

I’ve been trying to create separate workflows for:

  • building staging app
  • building production app
  • deploying staging app to Fabric Beta (using build staging workflow)
  • deploying staging app to TestFlight (using build staging workflow)
  • deploying production app to Fabric Beta (using build production workflow)
  • deploying production app to TestFlight (using build production workflow)

As the Fabric wants AdHoc provisioning profile and we use AppStore provisioning profile for TestFlight, I’ve created separate lanes to build the app for fabric (adhoc) and test flight (appstore).

I’ve come up with an idea I’d create separate workflows like this:

  • build-staging
  • build-production
  • deploy-fabric-staging
  • deploy-fabric-production
  • deploy-appstore-staging
  • deploy-appstore-production

The build-* workflows have the ENV variable FASTLANE_BUILD_LANE where I’ve put lane with params for specific app stage.
What I’ve wanted to achieve is when I run build for one of the deploy-* workflows, it would change the value of FASTLANE_BUILD_LANE env, so it builds the app in the previous workflow correctly.
So I’ve put different values for this env in the settings of these workflows.

Unfortunately, this doesn’t work as I expected, as it uses the env defined within build-* workflow instead of the next one (deploy-*).

Is there a way to achieve what I’m trying to do without creating multiple workflows for building the app?Example:

  • build-staging-fabric,
  • build-production-fabric,
  • build-staging-appstore,
  • build-production-appstore

Is there another way to override env value of previous step in workflows or read env value of next step?

2

Hy @arkus

If this would be a constant then I would add a script at the beggining of the deploy wokrflows with a content like this:

echo $FASTLANE_BUILD_LANE
echo "Overriding variable"
envman add --key FASTLANE_BUILD_LANE --value "your-deploy-lane"
echo "Done"

the strange part will be that if you would echo FASTLANE_BUILD_LANE in this step it would give you the old variable, but in the next step it would be the new one, like this:

11
111094×902 53 KB

3

@fehersanyi-bitrise
Ok, so just to be sure I’ve understood you, I should put additional step within deploy workflow to set the variable value to the desired build lane for that workflow, right?

What will happen when the build* workflow has the env value set in the Env Vars section?
Won’t it override the value set in the script from step 1?

4

@arkus that is exactly what I meant :upside_down_face:
the script will only override the env as long as the build runs with this method🤔
in this example I screen shotted, TEST_VAR is set on the env var tab, in the first script I echo it so we see that itssomething
then I changed with the envman tool to the other thing, and from that point in that build it will be that.

5

The issue here is that I can’t add one step before the whole workflow.
What I mean is that my deployment workflow uses build workflow as the previous workflow, so it looks e.g. like this: build-staging -> deploy-staging-fabric

When I’m in the workflow editor I cannot add just step before the build-staging workflow, I’d need to add another workflow to setup this, so I think it would be the same issue :thinking:

6

Oh I understand the issue, I was misunderstanding it,
what is the difference between build staging and build production?
is it only the branch? or are there any extra steps?

7

The main difference is the app scheme chosen to build with fastlane (so different params for the build lane) and different trigger branch.

8

maybe the best approach would be to have one build workflow, 2 deploy workflows, and four empty ones called

  • build-staging-fabric ,
  • build-production-fabric ,
  • build-staging-appstore ,
  • build-production-appstore

so 6 total, and chaining them after one another like you do now, and use workflow specific env vars :thinking:
so this way you don’t really make duplicates but can set up the 4 way separately

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.