I recently installed OS X Server on a seperate machine and attempting to host some git repos. When I try to create a new project & remote repo with Xcode I get an error -
Could not connect to the remote repository because the server was unreachable.
If I attempt to configure it again after the project has been created I get this error -
Cannot create hosted Git repositories at path because path already exists: /Library/Developer/XcodeServer/HostedRepositories/SampleProject
Looking at the server - I can see the repos were actually created, but for some reason I can't connect/push to them. I have tried this on the machine running the server and another one on the same network with the same results. Is something not configured correctly or any way to get at a more detailed error?
Fixed it by going into the Xcode service repository settings and enabling SSH access.
Related
I installed Git for Windows in order to clone and pull a project hosted on a remote Linux server.
In my repository (D:/repositories/my-project) I launch the following commands
git clone server#192.168.56.101:/var/www/web/my-project/.git
git pull origin master
So far so good. I pull the project files whenever modifications are applied on the server.
But now I'd like to pull or push from the remote server to my local repository.
I tried many things but I can't figure out how to access the repository located on my local machine.
Things like:
git pull duddy#my-pc:/d/repositories/my-project/.git master
just doesn't work, Git says:
ssh: Could not resolve hostname my-pc: Name or service not known
fatal: Could not read from remote repository.
Can someone helps me ?
First things first, I would recommend you try simply running git pull.
If this doesn't work, try running git remote -v and check to make sure that the URL for your server is listed as an origin (server#192.168.56.101:/var/www/web/my-project/.git).
Your issue is that you are inputting the URL for your local repository in your attempt to git pull.
I suggest reading the git-pull documentation to learn more about how pull works.
Basically, you need to have some service at your workstation which serves the requests. There are following options (I did not try most of them myself, just making it up from what I know):
use the windows file access. This is the easiest to setup at the windows workstation - just share the repository folder. The Linux side should somehow be able to mount windows shares (like described, for example, here: https://wiki.ubuntu.com/MountWindowsSharesPermanently). If you manage to mount your \\my-pc\repo to some /mount/my-pc-repo, then you can access it as file:///mount/my-pc-repo.
run git daemon at windows. Set up instructions are available at SO (for example, https://stackoverflow.com/a/2275844/2303202) and it pretty straightforward, but it does not have any authentication and in most cases it is reasonable to use it only for reading, so you will not be able to push to the workstation, only fetch.
set up ssh daemon and access through ssh authentication with read-write access. Git for windows installation contains the needed software (the sshd.exe binary, it is there at least for Git for Windows 2.6.0), probably there is a way to utilize it but I could not find it quickly.
set up HTTP(S) service at your workstation. I don't know if it is possible to do only with Git for Windows (it might be, with some perl module which happen to be included with it), or you should use some other software.
I need some help here, It's been a week I'm with this problem, can't figure out what's going on. I'm not able to clone a git repo from a slave node (Jenkins). I added the ssh key, host and slave (I've already tried generating a single key and one for each virtual and host)).
On Jenkins:
url:git#github.com: < repo>
Credentials: Here I tried with username/password, username with ssh file, username with ssh key directly, and -none-.
It doesn't seems like there is an authentication problem since I can clone the repo manually from console (both, slave and host). I can also connect with
ssh -T git#github.com
so the ssh key is fine, but when I build, this appear on console:
Building remotely on IE10Win7 in workspace C:\Users\IEUser\Desktop\<
folder >
Wiping out workspace first.
Cloning the remote Git repository
Cloning repository git#github.com:< repo>.git
git init C:\Users\IEUser\Desktop\< folder> # timeout=10
ERROR: Error cloning remote repo 'origin'
ERROR: Error cloning remote repo 'origin'
Performing Post build task...
Does anyone have an idea? Hope someone can give me a clue, Thanks!
I fixed this problem by setting the slave node tool path, selecting git and setting its value to
C:\Program Files (x86)\Git\bin\git.exe
Location: Configure Node - Tool Locations
I recently updated several jenkins plugins and had this problem after the updates. Rolling back the git plugin didn't help, but I did a few other things to get it working. I listed all three here, but it was probably (2) that fixed the problem. Apparently the git executable was reset to default. So, configuring the git executable within the specific project was probably all that was needed. However the other items might come in handy too.
(1) The default git on a jenkins linux install geenrally points to /usr/lib... You need to specify a separate GitForWindows that points to the windows version:
Manage Jenkins
Configure System
Under Git - Git Installations
Add Git -> Git
Give it a name to be referenced in projects
(mine is WindowsGit)
Set Path to Git Executable
(mine is "C:\Program Files (x86)\Git\bin\git.exe")
(for recent git the path is "C:\Program Files\Git\bin\git.exe")
(2) Configure git on the specific project:
Select the project
Select Configure
Under Source Code Management - Git
Select Git Executable as configured in 1)
Set credentials or add new (ssh keys, etc)
(3) Updating the jenkins slave service to run as a specific user:
Go to Windows Services on the slave -- StartMenu, type "services"
Select the Jenkins Slave service in the list on the right
Right-click and select "Properties" of the Jenkins Slave service
Select the "Log On" tab
Update the username and password used in manual tests
Domain login can be specificied with <DOMAIN>\<USERNAME>
Local logins just use <USERNAME>
OK to save and exit
Right-click again and select "Restart" to make the changes active.
I found a decent workaround in my case. The git clone command always inherits its process owner, which may make a difference, even if the two owners of Jenkins (SYSTEM) and cmd (USER) seem to have the same rights on your system. All other configurations were identical (keys, knownhosts, Git client version).
So as far as I can see, calling git clone from cmd will succeed because it calls the remote as USER, whereas git clone called from Jenkins may be rejected because it calls the remote as SYSTEM. In Services, where you would typically start Jenkins through the GUI, you can configure the service to run as a different user (right click on service --> Properties --> Log On). I had to put it like USER#DOMAIN, e.g. Jenkins#company.local or so. I'm not sure about how a cmd parameter would look, but I'd expect there to be one.
Also, I don't quite know what difference this workaround makes in the end, because on my Jenkins, SYSTEM and USER are configured to have the same rights across the system and they are of course both recognized as "Jenkins" by remote. Still, it does the trick for me. Deeper insights welcome.
I was facing similar problem and found that I need to add git to my PATH environment variable for a Windows based slave. I think that #dhj suggestion 2 might work as well in this case.
I found this workaround on Jenkins Jira.
In my case, I started getting this exact error after updating Git on some of my build machines (via Chocolatey, using the "git.install" package) from 1.9.4 to 2.5.0. The old 1.9.4 install was a 32-bit package but the new one is a 64-bit one, so the default install location switched from C:\Program Files (x86)\Git to C:\Program Files\Git. I had the 64-bit path configured on the Jenkins master (since it had the newer Git version), but some slaves still had the older 32-bit version installed, so the slaves were attempting to use an incorrect path. I could have overridden the Git path for individual slaves but the cleaner solution for me was simply to upgrade all the slaves to the newer 64-bit version.
I tried most of the above:
Specify git location.
Set service user.
Run as Administrator.
None of it worked. Eventually decided to uninstall git64 and install git32... changed the git path to the new location (in x86 Program Files). And everything worked.
I ran into this issue recently.
We had some items in our PATH EV which we had added when trying to connect Winium and Selenium to our Jenkins instance.
We removed these items, but still Jenkins seemed to be holding on to the values. After a bit of troubleshooting: restarting Jenkins; restarting the Jenkins server; setting the EVs at the node level; etc., we restarted the Jenkins JNLP service on the Windows slave.
And they lived happily ever after.
I also got the same error and fixed by adding a git path in the "Manage Jenkins -> Global Tool Configuration".
In my env, The windows Jenkins master run a job on the ubuntu slave machine, the master machine has used the default git ('C:\Program Files\Git\git.exe') path and the slave machine has used the git ('/usr/bin/git') path, therefore, I configured slave git path into the master configuration '/usr/bin/git' and its start working for me
My Company (Web Development) has decided to use Git. All repositories: employee (local repo) and remote repositories (bare repo) are stored on the central development server (OS X 10.9.1, Mac mini middle 2011). Developer connect to the development server from their iMacs over local network (OS X 10.7.5, 10.8.1 and so on, only Macs) and write the source code there. A Git client on Mac called Sourcetree should do the whole work. But after a few commits or some other git operations I get sooner or later following message:
fatal: unable to write new index file
After the message GIT can track the changes in the project, but I can't save anything to git. Even by using terminal or anotrher GIT-GUIs (I have tried Coda, GitHub) I get the same error message.
If the git client and the repository are stored on the same mac, everything works fine (tried on the development server and two iMacs). The problem occurs only if the git client has to connect to the repository over local network (AFP).
If I start the Git client on the development server and save some changes to the „damaged“ repository, everything works again. Also over local network. But if i work then in the repository on the development server with my local git client from my iMac over local network, I get sooner or later (mostly after a few adds or commits) the same error message.
I connect or login on server allways as the same user. Also Git client connects as the same user.
I suspect, that the reason is AFP.
I have enouth free space on the central development server. And have enouth file permissions, at least initially. These topics were not helpful for me:
https://apple.stackexchange.com/questions/111934/git-not-working-over-afp
GIT: "fatal: unable to write new_index file" while commit
git problem : fatal: Unable to write new index file
https://answers.atlassian.com/questions/155102/sourcetree-error-fatal-unable-to-write-new-index-file
Does Git generally choke on mounted drives? Or just Git GUI's?
What could I do?
We've run into the same issue repeatedly, especially as we try to use XCode 6. I'm currently changing over my connect to our server to WebDAV (connecting to our server via Finder > Go (menubar) > Connect to Server... > https://localnetworkIP/userfolder/).
This is working for us (so far).
UPDATE: After a few days, I noticed a new issue using WebDAV: files would disappear from view in the Finder causing XCode/Git to think that the file had been deleted. Looking at the server showed that the files were still there.
I then changed my connection type to SMB. This has worked well for me: Git no longer encounters file permission errors, and Finder (OSX 10.10 Yosemite) doesn't "loose" files.
I'm trying to host a git repository on my own webspace.
The repository has been set up via terminal+ssh and there were no problems, also I made a local clone of the repository with no problems.
Now I'm trying to use the github app to sync/push to the external repository which is causing big problems. The github app keeps prompting for the ssh password (I think its the ssh password - the box only says 'Password:'), even if I enter the correct one.
The url to the external repository seems to be correct, what have I done wrong (git beginner Oo)
ok, i found my error:
To sync your external non-github repository with your local one, your external repository mustn´t have the branch activated you want to sync.
i switched the external repository to an dummy-branch and then syncing works without problems...
I need some help.
I have a Windows Server 2003 computer that I'm setting up with Git and Review-Board.
My Git repositories are managed by Gitolite. The setup is successful and everything is working fine (tested with multiple workstations).
The Review-Board site has installed successfully and is hosted under Apache 2.2. This is also working fine in itself (the website is accessible and responds for workstations), except the part where I'm trying to link Git repositories to Review-Board.
Most tutorials (example: http://ericholscher.com/blog/2011/jan/24/using-reviewboard-git/) provide good details on how to setup a Git repository under Review-Board, except that they refer to Linux/Unix systems, and I am running Windows Server 2003.
My Gitolite repositories are stored under D:\Repositories\Git
Example: D:\Repositories\Git\sdu-test\.git
My understanding is that Review-Board needs a local clone of the repository(ies). Therefore, I created a directory named LocalClones and I cloned my repository.
Example: D:\Repositories\LocalClones\[I cloned sdu-test.git here]
Command used (from LocalClones directory): git clone ../Git/sdu-test.git(the clone was successful)
Now, in Review-Board, I'm trying to declare my sdu-test repository.
Name is 'sdu-test'
Hosting type is 'Custom'
Repository type is 'Git'
Path is 'D:\Repository\LocalClones\sdu-test' (I have also tried with 'sdu-test.git', and 'sdu-test/.git')
Mirror path is 'ssh://git#localhost/sdu-test' (I have also tried simply 'git#localhost:sdu-test', and no mirror path at all)
When I click Save, I get the following error: (11001, 'getaddrinfo failed'). I have no idea what to do about that.
If I try to change the path to a Unix-style path ('/D/Repository/LocalClones/sdu-test'), I get a different error message: Permission denied accessing the local Git repository '/D/Repository/LocalClones/sdu-test'. With a Unix-style path, I could even write a directory path that doesn't exist ('/I/Dont/Exist') and the same permission denied error is returned (the path in the error message does reflect the change though).
Can anyone help me out and tell me how to declare my local Git repository in Review-Board under Windows?
Thank you very much!
** UPDATE ** thank you Tamagochi and VonC for your answers, but unfortunately they're not working for me. Even after fixing the git.py file, I still get the Permission denied accessing the local Git repository '/D/Repository/LocalClones/sdu-test' error message.
There appears to be a bug in ReviewBoard 1.5.5 that causes this error. You can resolve this problem in either of two ways:
Move your repositories to drive C.
Edit \reviewboard\scmtools\git.py file, and replace the following line:
self.git_dir = url_parts[2]
with:
self.git_dir = url_parts[1] + url_parts[2]
Then use the following path: file://D:/Repository/LocalClones/sdu-test
I don't have any experience with ReviewBoard, but from what I can gather (from your link):
you do need to put the full path up to the .git directory of the local clone.
you should make your local clone through an url-based address. If the local file protocol is to be used, you should try with file///D/Repository/LocalClones/sdu-test.
git#localhost:sdu-test would only work if you have a git daemon running.
ssh://git#localhost/sdu-test would only work if you have a ssh daemon running.