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
Great idea @bernat_borras!
I’d say the closest to this is the Build Cache (Redirecting… - Bitrise Docs) . 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
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 
:
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:
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)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
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! 
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
Hi.
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! 
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.
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?
Hi @bpatch!
Have you tried using the Set Xcode Project Build Number step to offset the build numbers differently per workflows?
@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.