New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update GitWorktree/Rugged remote URL before pull if it has changed #22972
Update GitWorktree/Rugged remote URL before pull if it has changed #22972
Conversation
I'm concerned about timing/usage/locking conflicts here. On delete we know that nobody is using the directory (well maybe 😅). However if something is running and ensures the git repository, then something else deletes it, then the original usage code continues on it will hit an empty directory. |
I do see that it's WIP, but curious on your thoughts about that |
I was originally thinking we'd just broadcast an "update remote" command. I can't imagine it's hard to change the remote. |
Yeah...actually I don't think we know this on delete either 😆 so I agree we need locking around this. And yes that is why this is WIP (plus pending adding specs). On a multi-worker and more-so multi-appliance environment I don't think that deleting the record means that no one else is currently using the directory. We've seen issues like this with |
Yeah that's true I'll try that while holding the lock |
f243108
to
ebf2384
Compare
I ran into some issues with ordering of callbacks and what is being run by the queue first (ConfigurationScriptSource runs a sync on update, then the queued update was run). We already have an expectation that |
8a28bf8
to
bf5d757
Compare
Okay with this change I'm able to create a ConfigurationScriptSource pointing to |
e7774e0
to
44d5c55
Compare
Checked commits agrare/manageiq@c0739ae~...44d5c55 with ruby 2.7.8, rubocop 1.56.3, haml-lint 0.51.0, and yamllint |
If the URL of a
GitRepository
is changed after the sparse repo is cloned then we have to update the local remote url before fetch+merge in order to pull from the correct url.Fixes #22970