Save state between build



We have a step configuration that it fails it sends a message to Slack, but if it runs successfully, it not send anything.

but, once it failed, if next build is green, I would notify slack to say “hey, the build has been fixed! Good job”

Is there any way to keep any value somewhere and retrieve it? Something like “key/store” value.



Great idea @bernat_borras!

I’d say the closest to this is the Build Cache ( . With that you can store info into a file and then retrieve it in the next build.

To expose env vars for subsequent steps you can use envman:


It’s a very, very rough base script, “work in progress” if you like (wasn’t written for this problem originally, just tweaked it a bit), but might be useful as a starter :wink: :

    - cache-pull@2.0.1: {}
    - script@1.1.5:
        title: check if changed
        - content: |
            #!/usr/bin/env bash
            set -ex

            if [[ -f "$build_status_file_pth" ]] ; then
              last_successful_build_number=$(cat "$build_status_file_pth")
              if [[ $(( $last_successful_build_number + 1)) == $BITRISE_BUILD_NUMBER ]] ; then
                # previous build was successful
                # previous build was not successful
                envman add --key 'IS_PREV_BUILD_FAILED' --value 'indeed'
    - random-quote@3.0.2:
        is_always_run: false
        run_if: '{{ enveq "IS_PREV_BUILD_FAILED" "indeed" }}'
    - script@1.1.5:
        title: save current build's status
        - content: |-
            #!/usr/bin/env bash
            set -ex


            # store current build number
            echo "$BITRISE_BUILD_NUMBER" > "$build_status_file_pth"
    - cache-push@2.0.3:
        - cache_paths: "$BITRISE_CACHE_DIR"

Couple of notes:

  • A Step by default does not run / gets executed if a previous step failed. is_always_run: false makes this explicit in the config, e.g. the Slack step is one of those steps which is marked with is_always_run: true so that it also runs when the build failed.
  • run_if can be used to mark a step to only run if a simple expression evaluates to true (
  • In this example random-quote is the step which is meant to be only performed if this build is successful (is_always_run: false) AND only if the IS_PREV_BUILD_FAILED env var is set to the value indeed (which is set by a previous Script step, in case the prev build’s number is not the current -1)

Again, this is just a sample “layout”, unfortunately I did not have more time right now to make this an actual working example, so treat it as a “starter” script :wink:


Wow thanks, I will try this snippet!

I guess it could be a good base for a new step?


If you have any questions just let us know! :wink:

Might be indeed, although it’s one of those which would require a guide actually as e.g. it relies on the Build Cache mechanism :slight_smile:
But if you’d have some time creating the step and would have any questions just let us know! We’re always happy to help / answer questions :wink:


Is Bitrise Cache dir a good place to store some custom variables?
It will be cleaned up after some time, won’t it?


Hello @dima_ost!
I would suggest you use the Env var or the secrets tab on the workflow editor to store custom variables! :slight_smile:


Thanks, but I’d like to increment it for each build in workflow. There was suggestion to use bitrise cache, so I asked about cache lifetime


The Build Cache, related to a specific branch, expires/is auto-deleted after 7 days, if there’s no new build on that branch in the meantime. This means that if you do builds on a specific branch every day (more frequently than a week), it’ll never expire/won’t get deleted automatically. If you don’t start a build on that specific branch for more than 7 days, then the related cache will be removed, and your next build will run like the first time, when there was no cache for that branch yet.


Thank you. Do you plan to add build number env per workflow in future?


Hey it is $BITRISE_BUILD_NUMBER but it is on the app itself, not workflow specific, for you can kind of chain them like lego pieces so it would not make sense.


I’d like to increment version number for release builds independently of pull request builds, to prevent release version code ‘jumping’ like 101 - 300 - 500. I’d like to have release version codes sequence like 101-102-103


hm, you can do it like this in my opinion, in the deploy workflow add the set android manifest version code and name step. if you use android ofc. and only those builds will change the version . number, the test workflows and the development ones don’t.