Hi, we are trying to update our workflow to use the new osx-xcode-15.3.x stack and are having an odd issue. Wondering if anyone has seen anything similar or has any insight into what is happening.
On the new stack, the first build passes fine.
A subsequent rebuild fails on git clone step. It errors saying as it claims the git repo already exists.
By deleting the cached files for the branch it is possible to make it pass again. So something (the git repo?) seems to now be in the cache on the new stack.
This behaviour didn’t happen on the previous stack and nothing else has changed in the workflow.
Update - just noticed on the branches using the new stack, the cached files are 8.5Gb rather than 350mb. Conclusion - the legacy cache step is broken on the new stack and caches the whole repo, not just the specified files. I’m going to try migrating to the key based cache step to see if that resolves the issue
After some more digging last night - have come to the conclusion the legacy cache step is not broken after all. There seems to be some difference in the way ruby is set up on the new stack that is breaking the script we were using to set an environment variable used to set the path to cache. It’s supposed to point to the ruby gems directory, but on the new stack ends up pointing at Users/vagrant/git instead. - hence everything is getting cached!
The troublesome script is this:
envman add --key GEM_RBENV_CACHE_PATH --value “cd $$(rbenv which ruby)/../..;pwd”; \
works fine on old stack, resolves to root directory on new stack.
I’m updating with a different approach now that I’m hopeful will resolve the issue: