Stale git cache? Follow
How is the /build/system/git cache added to an agent AMI instance?
On my agent there is clearly missing cache entries. The map file is incomplete and the cached git repo is missing too.
I say missing as the Admin page: /admin/admin.html?item=diagnostics&tab=dataDir&file=system/caches/git/map
clearly shows the cache entry I'm expecting to be there.
Please sign in to leave a comment.
> So I guess after the agent / build succeeds in cloning the repo TeamCity gets the .git/objects directory & makes the alternate objects dir cache entry from that?
> But I confess I do not know what "re-capture it as a new version of AMI" means.
You have mentioned that your agents are instances of AMI; for cloud agents, common approach is to create a "reference" machine, make sure it has the necessary tooling and configuration and capture a snapshot of that machine to clone it when new instances of a cloud agent are needed. In terms of Amazon, that snapshot would be called AMI.
You (or the persons who are responsible for handling AWS part of setup) could capture an AMI of agent that has necessary repositories checked out, so that newly-created agents start from that state, speeding up the builds.
TeamCity keeps a mirror of each Git repository in the Git cache on the server side - this is what you see in the system/caches/git/map under the Data Directory. However, on agent machines TeamCity will checkout repositories on demand (when a corresponding build is started).
You may re-capture an agent AMI with up-to-date version of cache to speed up the checkout - would this work for you?
I'm not sure.
So our checkout code does in summary)
git init .
git add remote origin main <the repo>
But we look for the local cache git repo in the cache map & put it into GIT_ALTERNATE_OBJECT_DIRECTORIES
And that works just fine for repos that are in the cache.
My issue is that the main system cache DOES have the remote repo I need cached.
But my AMI instance does not.
I'm not sure how it gets updated. Perhaps this is something the admins do?
> something that admins do
No-no, the cache is populated when agent runs checkout for that repo. Suppose you have a build configuration B which has a VCS root V attached. On the server side, V will always be in the git cache, but on the agent side it will be checked out only when B was executed at least once on that agent.
In your case, you could start the machine that was used as a base for AMI image, run a build that has the repository in question attached as a VCS root, ensure the git cache is populated and re-capture it as a new version of AMI. Would that help?
So I guess after the agent / build succeeds in cloning the repo TeamCity gets the .git/objects directory & makes the alternate objects dir cache entry from that?
But I confess I do not know what "re-capture it as a new version of AMI" means.
Likely as I've not had to work with the AMIs at all in our TC install.