A very useful feature would be the ability to persist some variables through builds. For example, if my last build was Android version 1.0.1, I don’t want to build again (and notify my Slack tester channel) until the version is bumped to 1.0.2. I would like to store a persistent variable, e.g. LAST_VERSION_NAME, and check against that with a bash script at the start of each build. Any way to do this with current build steps / does this seem like a reasonable feature to implement?
You might be able to do this with the Build Cache - just add the
Cache:Push steps to your workflow (cache:pull will download the cache if available, and cache:push will update/upload it if required - if any file changes), and if you don’t change the configurations (what to cache), you can just write into the
$BITRISE_CACHE_DIR directory and that will persist between builds.
An important note though (highlight from the Build Cache docs):
If you write into the cache on a
feature/ branch, that will only be available on that specific branch. E.g. the cache of
feature/a won’t be available for
feature/b, but will be available for every subsequent build of
feature/a (until the cache expires, if you don’t use it for a while).
The only exception is the cache generated by the “primary” branch (the one you set on the
Settings tab as the primary branch). If
feature/c doesn’t have a cache yet, it will get the cache of the “primary” branch until it writes into its own cache.
The build on a non default branch, to speed up things, can (read-only) access the primary branch’s cache, until a successful build on the new branch. Once a build on the new branch pushes a cache, new builds on that branch will get the branch’s cache. Caches are stored and available for every branch separately.
This is quite useful for regular dependencies, as you most likely want to utilize the default/primary branch’s cache when you start a new branch, but in your case you have to be aware of this. Of course this can be useful too, to not to send notifications from “feature/” branches until you bump the version number.
If you want to handle this case, that the cache is for the primary branch, you can e.g. write the current build’s
$BITRISE_GIT_BRANCH into the cache file, and then compare it in the Script with that build’s
$BITRISE_GIT_BRANCH. If that’s the same, then the cache was generated by the branch. If it’s not the same, then the cache was generated by the primary/default branch and you can decide how you want to handle it (e.g. ignore it).
If you have any questions, just let us know!
Thanks! I think I’ll be able to do what I need with the Cache steps
i do not really see the use case of this feature.
You can define multiple workflows to separate what to do during your automations.
For example, if your are working on develop branch and you want to test the changes on this branch, you should setup a ci workflow, which runs your tests and triggered by a push/pr on develop branch.
Once you finish a major feature and you want to let your testers to test it, you may push your changes on master branch, which triggers another workflow (primary for example), which runs your tests, generates the artifact to test and notify your testers. So primary workflow would be triggered by push/pr on master or even by tagging your source code’s current state.
Once your are ready for release your app, you may push your changes to the release branch, which triggers a workflow (for example release), which runs your tests and deploys your artifact.
So to separate tasks to be done based on your source code’s state, i recommend to define multiple workflows, instead of using persistent variables.
True, I definitely agree that if you can use multiple workflows that’s a way better solution, just wanted to mention that in case you actually need a persistent storage between builds, the cache can be utilized (but limitations have to be considered of course).
With react native the release strategy is a lot more complicated. If there are native changes you do a binary update if not you do a code push and periodically you do a binary update with the latest js code. For releases this could be achieved with a complex branching strategy but there would be no way to have an alpha build that just fallows the develop branch. You could compare files with the last commit but that only works if the last commit was deployed. It would be much easier if there was a way to persist the commit id when the build is deployed.