Add a vagrant file and provisioning script #206
Conversation
|
This branch seems to cause problems for git/bundler for reasons I don't yet understand. I frequently get these sorts of errors from running I think it may have to do with the fact that there used to be a branch called @dlecocq -- do you mind deleting this branch and repushing it as |
|
The branch on github has been deleted, so you just have to delete your local one (I imagine). Have you tried giving the command they suggest a shot? Specifically |
|
Yes, I've given the command a shot. It fixes it temporarily and then it comes back some time later. This has happened multiple times over the course of months. I only got annoyed enough to comment here when it happened yet again yesterday. |
|
I'd delete your local repo and re-clone. That's what I did when I encountered this a while back. |
Which repo are you talking about -- vanguard (the consuming repo referencing Qless via If it's the latter...I believe I've done that, a couple of times, and it's still come back. If it's the former...cloning vanguard can take quite some time, so I'm loath to do that but I may try that at some point. Although, this problem seems to go away for a while and then come back for some reason so it's hard to say if it's ever really fixed :(. |
|
So we just ran into this error again in our prod servers (after not seeing it for a month or more): I'm going to work on fixing this in prod...but we've applied fixes in prod for this 3-4 times before. @dlecocq, would you reconsider blowing away this branch and pushing it under a different name to avoid this issue? |
|
I don't see why you think deleting this branch is going to solve the problem. The supposedly conflicting branch named |
|
do we do /Vadim On Fri, Apr 10, 2015 at 11:54 AM, Brandon Forehand <notifications@github.com
|
It certainly might not solve the problem. But it certainly might. The error message always names this branch as causing a problem, and given that, and the fact that we've already wasted many hours trying to solve this problem on our end over the last 6 months, why not spend the couple of minutes it would take to move this PR to a different branch name? We've already tried many things. Admittedly, I don't fully understand why this problem occurs given that we delete the local ref and it later comes back, but yet the problem continues to periodically return.
I definitely don't know what's going on. We've repeatedly removed the local references and yet this problem resurfaces. Usually after a few weeks. So yes, it's very odd.
|
|
|
That should not be necessary. The issue appears to be that once upon a time there was a branch called |
|
I believe we've done the @GreyKn -- can you speak to what you've done on the prod servers to deal with this when it periodically occurs? I can understand why you think that my suggestion may not work. Is anyone opposed to me trying it, though? Maybe I will waste a few minutes, but that's my perogative to waste my own time. I don't understand the resistance to trying a different technique than what we've already tried. |
|
I don't mind you wasting your time Myron. ;) I just want to help you find the root cause. Are you doing anything weird like pushing branches directly to these machines? It sounds like someone is explicitly reviving the |
Nope.
I don't believe that can be the problem. On deploy we don't run any git commands to fetch qless. It's bundler that does that. It does it based on the git reference in our I supposed bundler could be doing something weird... |
|
Our cap deploys will fail with a fatal error when this occurs. To fix it, I need to ssh into the affected machines and rm the bundler shared cached copy of the git repo to allow deploys to succeed. Location: |
|
FWIW, here are the git commands bundler is using: https://github.com/bundler/bundler/blob/v1.6.1/lib/bundler/source/git/git_proxy.rb#L63-L75 It does fetch all the refs, but given that the ref has been deleted from github, that shouldn't cause this to resurface. ...and yet it does. Makes me wonder if there's some latent GitHub bug where a deleted branch can later temporarily be included in the list of refs again. |
|
Do we do this issue right now? I'd like to `telnet` to Mordor and explore
that a bit.
|
|
By the way, I wasn't saying that your deploy code was issuing the I also ran these exact commands on my local machine: mkdir /tmp/blah/
cd /tmp/blah
git init --bare
git fetch --force --quiet --tags 'git://github.com/seomoz/qless.git' "refs/heads/*:refs/heads/*"And the If there's no other way to resolve this, I guess Dan can try renaming the branch. I don't see how that will help, but I guess it can't hurt. |
No, @GreyKn |
|
it would take long: I will just copy /Vadim On Fri, Apr 10, 2015 at 1:09 PM, Myron Marston notifications@github.com
|
|
*would not |
|
I've updated this branch because I needed an environment for #246 -- it took some fiddling with dependencies to make it happen. |
|
I destroyed my vagrant and reprovisioned it and successfully ran tests. Big caveat, the headless tests don't all pass (similar to the flakiness in Travis), and so I needed to run with |
In the course of helping @vadim-moz debug, I ended up creating a provisioning script and Vagrantfile. Helpful for those on a new machine, wishing to hack on it, etc. for getting up and running with a development environment.