I have installed msysgit, and I am attempting to use it inside of Hudson. Whenever I run a command in an interactive shell, whether it be git-bash or a command prompt, the commands are instant. When I run them in Hudson, they lag for a very long time.
Running /bin/git help took 63 seconds when I just invoked it. I've never waited long enough to see a clone begin outputting (>10 minutes).
The Hudson mailing list is down, so I figured I would try here...
I've run into this problem as well, and figured out a workaround. When Hudson runs as a service, something is missing that your normal desktop environment has, which causes something to do with the network to have to re-load for each process. msys-1.0.dll attempts to load something in netapi32.dll which causes it to take so long. So I just downloaded plink.exe from PuTTY, and set my GIT_SSH env to use that instead. Problem averted.
Have you tried using the Git plugin for Hudson?
Related
Very often when running ansible-playbook on the Vagrant VM from Windows, I need to stop in the middle of something by pressing Ctrl+C. This happens if ansible becomes unresponsive or there is some bug we need to fix asap, so there is no point of waiting until provisioner completes.
The probem is that Ctrl+C does not work, some 2 ruby.exe processes get stuck in process tree. Any subsequent vagrant commands fail until you manually kill these ruby processes.
I also use to kill all stucked python ansible processes on the VM before running new provision.
Any way to handle it more jently?
I found this problem as well on Windows and using Puppet Apply. The only way I can happily kill it by opening another terminal/cmd and then vagrant ssh -- sudo pkill puppet. That gracefully terminates the process, and allows me to regain control of my first terminal again.
In short the solution is:
Take a terminal that works.
I find one working gitbash v2.32.0.windows..
The latest available gitbash currently is v2.38.1. But only the old one is working correctly with Vagrant(Oracle VM). The strange thing is that the latest one (gitbash v2.38.1) is working fine with SSH connections to AWS EC2 instances.
Alternatively. Windows PowerShell is working fine with Vagrant(Oracle VM).
If someone needs my bad experience, here it is.
The following terminals DON'T WORK
gitbash v2.38.1 (latest for now)
gitbash V2.36.0
ConEmu v220807 Alhpa (latest for now)
cmder v1.3.20.1282 (latest for now)
I propose using vagrant halt.
Recently while at work we were given an older version of ubuntu (12.04) to work with on a vagrant machine.
I wanted to migrate over to fish or zsh due to them being way better then default bash but I'm encountering a weird error where if I navigate to the /vagrant folder (shared onto the local machine as well) every command I run stalls for 5-10 seconds. Outside of the folder it does fine and has no stalling problems.
Has anyone encountered this before or have any ideas on why this could be happening?
Probably some stat or something taking too long to finish. I will suggest to run strace on bash (if you have patient for that :) ).
Such stat can be for example called from your PROMPT, it's common to have there CWD.
I will suggest to not run commands from there if not necessary. You can call commands outside and provide path to there.
Ofcourse you can play with sharing, there is probably some weak point.
I cannot for the life of me seem to get my Jenkins CI to work with Github.
I had failure on the clone command, but that was due to keys, so I logged in as service account (the user Jenkins runs under as a Windows Service) and ran the clone command. All good in the hood.
However, when I want to run the fetch to get latest, it won't finish. It just sits there. I have tried via the Git plugin for Jenkins, and also via a Windows commandline script. Neither work. However, if I open a command prompt and type the command in, it works!
So how do I get it to work via Jenkins?
I run this script:
set
"C:\Program Files (x86)\Git\bin\git.exe" fetch -t ssh://git#github.com/OrgName/MyRepo.git +refs/heads/*:refs/remotes/origin/*
exit 0
and it sticks on the fetch command, never exiting.
Does someone have any suggestion?
It looks like msysGit stuck trying to find one of its components, used during fetch operation.
The Git itself not a single executable actually. It's a set of small tools doing their job great only being put together. Running Git on Windows from bash prompt makes it happen, but when you're running via Windows command prompt or in batch-files, the Force may not be with you.
I think you should check wherever you installed msysGit with option "Run Git from Windows Command Prompt". In this case all needed parts of Git will be added to the system PATH variable and git.exe will be able to access it from batch files, thus it should fix your fetch statement.
I'm having trouble getting post-recieve and post-commit hooks to work correctly with msysgit (Windows 7 Pro/32 and Ultimate/64). For post-commit hook I get the above error if I commit from either git-bash or the console, but it works fine if I commit through git-gui. For a post-recieve hook, all three give the same error.
I'm thinking this is some sort of permission or path error, but don't really have any clue where to start here.
Add the SHEBANG to the first line of hook, like so:
#!/bin/sh
echo "executing post-commit"
exit 0
This had me stumped for a while as well and I saw that adding the shebang fixed it. In SVN world, while in *nix we have a "pre-commit" script and in Windows we had "pre-commit.bat" and SVN automatically picked up the bat file in Windows. Git doesn't seem to pick up a pre-commit.bat ( or any hook ) and adding the shebang to the hook file worked.
I'm using SourceTree and git LFS and had a similar issue: cannot spawn .git/hooks/pre-push.
The fix was to delete the pre-push file (opening it revealed it was badly corrupted) and restart SourceTree at which point it regenerates the pre-push file and everything is back to normal.
If you have the SHEBANG and it still fails, make sure you have <path_to_git>\bin set in your path environment variable.
You'll probably also have <path_to_git>\cmd if you installed it to work from the command-line.
This is an old question, but I've been fighting with this exact problem and this SO question popped up, so I thought it worth the effort to record what worked for me.
In short: I needed to run Apache as a regular user instead of Local System. This was on a legacy test VM I was playing with, so it was only running Windows XP, but it appears that at least on that platform (and possibly others), msysgit just doesn't work properly when running under the Local System account (presumably the root filesystem isn't mapped properly). As a result, no shebang line will work as git-http-backend simply can't execute any msysgit binaries (even with absolute Windows paths).
Switching Apache to run as a regular user account fixed this problem completely. Obviously you need to ensure that the user Apache is running as has permissions to read/write the git repositories, but beyond that, just make sure your shebang line is #!/bin/sh and everything should be copacetic.
Lastly, yeah, this is a big hammer. Ideally you'd be able to use something like suexec on Windows, but a quick googling doesn't indicate an obvious path forward, there. Of course, if anyone has any ideas, I'd be interested.
For now, this works for me, but it doesn't seem ideal.
Got this in a repo using LFS, got rid of it with git lfs update --force
If someone, like me run into a similar problem with accessing git repositories through apache, you should set the PATH in Apache config, like:
SetEnv PATH "c:/Program Files (x86)/Git/bin;"
Using tortoisegit and LFS, for me just had to remove the files inside of the .git/hooks folder.
If you are using Android studio, you can remove this error by un-check the checkbox "Run Git hooks":
For me, removing a comment line on front of the shebang line fixed the error. Oddly, the script ran fine from the shell, just errored out when run as a hook.
I am trying to run a shell script lets call it fml.sh on my windows slave machine.
I have installed msys. I can run the script from cmd with the following call.
C:\msys\1.0\bin\sh.exe -e -x "C:\path\to\fml.sh"
Now in my build pre-build code I run that very same line from within hudson I get the following response.
AllocationBase 0x71590000, BaseAddress 0x715B0000, RegionSize 0x38000, State 0x1000
C:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487
My mind is boggled, and very much bothered.
Does anyone else know of a way to run a script on a windows slave from within Hudson.
Very same thing happens with bash.exe as well.
Please and thank you.
I found a link online that says that the problem can be resolved by running the following:
$ rebase -b 0x30000000 msys-1.0.dll
I haven't tried it but I am hopeful.
Edit: this is confirmed and solved my problem. I had to do a bit of googling to get the rebase.exe
If you are using Cygwin, rebasing is an issue that can affect many dll's so you might need to rebase more dlls. This link explains simple steps to rebase all dlls and also has an explanation why it happens.