Release library part 4
• Mark Eschbach
So I’ve got the merge in the original state. Which is great because now I need to figure out how to fail the test case. To generate the unique build number for iOS we use something along the lines of git rev-list HEAD | wc -l
. Hmm, after nearly a year we haven’t hit a collision with this technique however I could definitely see that as a possible problem in the future. Upon running this command I realized it will always track the first parent of the commit. When successful that should be the same count. For this test I need to test the total number of commits along all paths to ensure they equal two less than the failing run. I’m not entirely sure if the --all
option is what I’m looking for on git-rev-list
. git rev-parse --all |wc -l
works for now, giving me the 6 commits instead of the expected 4.
Not having a remote repository is really tripping up the scripts. I think I might be better off setting up the harness to create the remotes and check out the correct local state. This would reduce the friction between the test environment and proudction environments + allow me to take out a knob related to pushing and pulling.