# Save state between build **URL:** \ **Category:** Question & Answer\ **Created:** [January 18, 2018, 3:29pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800 "2018-01-18T15:29:25Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![bernat](https://avatars.discourse-cdn.com/v4/letter/b/9d8465/32.png) [@bernat](https://discuss.bitrise.io/u/bernat)\ **Post date:** [January 18, 2018, 3:29pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/1 "2018-01-18T15:29:25Z")
Hi. 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. thanks ---
**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\ **Post date:** [January 18, 2018, 5:08pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/2 "2018-01-18T17:08:47Z")
Great idea @bernat\_borras! > [@bernat\_borras](#): > > Is there any way to keep any value somewhere and retrieve it? Something like “key/store” value. I’d say the closest to this is the Build Cache ([Redirecting… - Bitrise Docs](http://devcenter.bitrise.io/caching/about-caching/)) . 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`: [Environment Variables - Bitrise Docs](http://devcenter.bitrise.io/tips-and-tricks/expose-environment-variable/) ---
**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\ **Post date:** [January 18, 2018, 5:58pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/3 "2018-01-18T17:58:35Z")
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_** 😉 : ```auto steps: - cache-pull@2.0.1: {} - script@1.1.5: title: check if changed inputs: - content: | #!/usr/bin/env bash set -ex build_status_file_pth="$BITRISE_CACHE_DIR/build-status" 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 else # previous build was not successful envman add --key 'IS_PREV_BUILD_FAILED' --value 'indeed' fi fi - 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 inputs: - content: |- #!/usr/bin/env bash set -ex build_status_file_pth="$BITRISE_CACHE_DIR/build-status" # store current build number echo "$BITRISE_BUILD_NUMBER" > "$build_status_file_pth" - cache-push@2.0.3: inputs: - 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 ([http://devcenter.bitrise.io/tips-and-tricks/disable-a-step-by-condition/#run-a-step-only-if-the-build-failed](http://devcenter.bitrise.io/tips-and-tricks/disable-a-step-by-condition/#run-a-step-only-if-the-build-failed)) - 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** 😉 ---
**Author:** ![bernat](https://avatars.discourse-cdn.com/v4/letter/b/9d8465/32.png) [@bernat](https://discuss.bitrise.io/u/bernat)\ **Post date:** [January 19, 2018, 8:34am UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/4 "2018-01-19T08:34:57Z")
Wow thanks, I will try this snippet! I guess it could be a good base for a new step? ---
**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\ **Post date:** [January 19, 2018, 10:26am UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/5 "2018-01-19T10:26:42Z")
> [@bernat\_borras](#): > > Wow thanks, I will try this snippet! If you have any questions just let us know! 😉 > [@bernat\_borras](#): > > I guess it could be a good base for a new step? 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 🙂 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 😉 ---
**Author:** ![dima\_ost](https://avatars.discourse-cdn.com/v4/letter/d/e47774/32.png) [@dima\_ost](https://discuss.bitrise.io/u/dima_ost)\ **Post date:** [November 5, 2018, 10:53pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/6 "2018-11-05T22:53:26Z")
Hi. Is Bitrise Cache dir a good place to store some custom variables? It will be cleaned up after some time, won’t it? ---
**Author:** ![fehersanyi-bitrise](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/fehersanyi-bitrise/32/1912_2.png) [@fehersanyi-bitrise](https://discuss.bitrise.io/u/fehersanyi-bitrise)\ **Post date:** [November 6, 2018, 2:02pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/7 "2018-11-06T14:02:17Z")
Hello @dima_ost! I would suggest you use the Env var or the secrets tab on the workflow editor to store custom variables! 🙂 ---
**Author:** ![dima\_ost](https://avatars.discourse-cdn.com/v4/letter/d/e47774/32.png) [@dima\_ost](https://discuss.bitrise.io/u/dima_ost)\ **Post date:** [November 6, 2018, 9:18pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/8 "2018-11-06T21:18:06Z")
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 ---
**Author:** ![fehersanyi-bitrise](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/fehersanyi-bitrise/32/1912_2.png) [@fehersanyi-bitrise](https://discuss.bitrise.io/u/fehersanyi-bitrise)\ **Post date:** [November 7, 2018, 8:56am UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/9 "2018-11-07T08:56:02Z")
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. ---
**Author:** ![dima\_ost](https://avatars.discourse-cdn.com/v4/letter/d/e47774/32.png) [@dima\_ost](https://discuss.bitrise.io/u/dima_ost)\ **Post date:** [November 7, 2018, 1:33pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/10 "2018-11-07T13:33:17Z")
Thank you. Do you plan to add build number env per workflow in future? ---
**Author:** ![fehersanyi-bitrise](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/fehersanyi-bitrise/32/1912_2.png) [@fehersanyi-bitrise](https://discuss.bitrise.io/u/fehersanyi-bitrise)\ **Post date:** [November 7, 2018, 1:37pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/11 "2018-11-07T13:37:25Z")
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. ---
**Author:** ![dima\_ost](https://avatars.discourse-cdn.com/v4/letter/d/e47774/32.png) [@dima\_ost](https://discuss.bitrise.io/u/dima_ost)\ **Post date:** [November 7, 2018, 8:43pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/12 "2018-11-07T20:43:44Z")
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 ---
**Author:** ![fehersanyi-bitrise](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/fehersanyi-bitrise/32/1912_2.png) [@fehersanyi-bitrise](https://discuss.bitrise.io/u/fehersanyi-bitrise)\ **Post date:** [November 8, 2018, 7:36am UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/13 "2018-11-08T07:36:10Z")
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. ---
**Author:** ![bpatch](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/bpatch/32/2805_2.png) [@bpatch](https://discuss.bitrise.io/u/bpatch)\ **Post date:** [February 26, 2020, 9:23pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/14 "2020-02-26T21:23:30Z")
Is there a way to do this for iOS? Currently it seems the $BITRISE\_BUILD\_NUMBER is incremented any time any workflow is executed, and I’d rather only increment the build number by one each time I release (so release versions would be 2.51, 2.52, 2.53, etc. rather than 2.51, 2.73, 2.95 etc.). This seems like a logical feature, so maybe I’m just missing a super simple step or something… I was thinking maybe I could update an environment var each time the Deploy workflow is executed, but `envman` doesn’t seem to be able to overwrite the environment variables outside of the workflows execution. I could also write to the cache like mentioned above, but then I’d need to execute the script each week to keep the cache alive, which seems awkward/defeats the purpose. Thoughts? ---
**Author:** ![bitce](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/bitce/32/1639_2.png) [@bitce](https://discuss.bitrise.io/u/bitce)\ **Post date:** [February 27, 2020, 8:49am UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/15 "2020-02-27T08:49:07Z")
Hi @bpatch! Have you tried using the Set Xcode Project Build Number step to offset the build numbers differently per workflows? ---
**Author:** ![bpatch](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/bpatch/32/2805_2.png) [@bpatch](https://discuss.bitrise.io/u/bpatch)\ **Post date:** [February 28, 2020, 4:40pm UTC](https://discuss.bitrise.io/t/save-state-between-build/3800/16 "2020-02-28T16:40:55Z")
@bitce So my situation is the project has a version number of 1.0 but we’re really on like 2.54. Previously we’ve been using Jenkins and calculating the build number on tags of commits, but I don’t love that approach cause it can get buggy. We are using the Set Xcode Project Build Number step, but as I understand it, the offset just add’s a static number to the number of the project. So if I said the offset was 7, then it would take our build number from 1.0 to 8.0 or maybe 1.7, but that wouldn’t increment to 1.8 and 1.9 each time the workflow runs again, right? Cause the offset is still a static “7” and the project will still have a version number of 1.0. Am I misunderstanding how that step works? In my mind, I either need to update the project and commit/push that change each time I want to up the version number or I need to have an environment variable that I can increment manually or only when a specific workflow runs.