Git rev-list HEAD --count gives strange results on circleCI server

We are building an iOS app using fastlane/gym. The target has as a dependency a script which does buildnum=$(git rev-list HEAD --count) and assigns that to the build number in Info.plist. For some reason, the resulting ipa has buildnumber 20 when built on circleCI server but 148 when I build it locally.

I have checked that it really does read the number of commits - when I add one commit, it changes to 21 on circleCI and 149 on my machine. So I am confident that I have pinpointed the issue, git rev-list HEAD --count must be giving different results on circleCI server. Any idea why this might be happening?

1 Like

When we first checkout your code after you set up the builds on CircleCI, we do a shallow clone thus downloading only 10 most recent commits around the tip of each branch you have in your GitHub repo. That is where the smaller number of commits on CircleCI comes from.

After the first checkout, a source cache is created, and further checkouts are based on what is already present in the cache to reduce checkout traffic and time. This is the reason why adding a new commit resulted in 21 rather than 20—but clearing the source cache will bring that value down to 10 (we fetch only 10 most recent commits).

To work around this you might want to unshallow the repo—download all the commits—by adding the following to your circle.yml:

    - "[[ ! -s \"$(git rev-parse --git-dir)/shallow\" ]] || git fetch --unshallow"

Another thing you might want to do is to use a different system for generating the buildnum variable, for example $CIRCLE_BUILD_NUM is one of the env vars we populate each build with, and it is guaranteed to be incremented from build to build.


thanks, I suspected something like this but I didnt know about this git feature. I havent yet tested your solution but it makes sense and I presume it will work. Marking this as solved.


Can I edit the build number from my repository in circle ci?

I can use the $CIRCLE_BUILD_NUM only if it big than my currently commit count, since I was using the commit count as build number previously.