In TeamCity 9 (windows) I have an existing hg repo that I would like to incorporate into a new TC project.
However I am getting an error when the build agent runs, suggesting that is trying to 'hg init' the repo.
The error message is :
"C:\code\xxxx\"}: 'hg init' command failed.
stderr: abort: repository . already exists! "
This seems like very basic configuration issue, I have performed this setup in older versions of TC..
Updated with more info as requested :
VCS root has a 'HG command path' of 'hg'
The latest build log is :
Build 'TestProject :: TestBuildConfig' #7
Started 'Tue Aug 04 12:26:18 BST 2015' on 'PCUKDZKBP32' by 'James (tcadmin)'
Finished 'Tue Aug 04 12:26:18 BST 2015' with status 'FAILURE Unable to collect changes'
TeamCity URL http://localhost:8090/viewLog.html?buildId=24&buildTypeId=TestProject_TestBuildConfig
TeamCity server version is 9.1 (build 36973)
[12:26:18]i: TeamCity server version is 9.1 (build 36973)
[12:26:18]E: bt2
[12:26:18] : Collecting changes in 1 VCS root
[12:26:18] : [Collecting changes in 1 VCS root] VCS Root details
[12:26:18] : [VCS Root details] "TestRoot" {instance id=20, parent internal id=2, parent id=TestProject_TestRoot, description: "mercurial: c:\code\TestProject\"}
[12:26:18]i: [Collecting changes in 1 VCS root] Loading current repository state for VCS root 'TestRoot'
[12:26:18]i: [Loading current repository state for VCS root 'TestRoot'] VCS root 'TestRoot': [C:\Windows\System32\config\systemprofile\.BuildServer\system\caches\mercurial\hg_4258089649368462685] hg init
[12:26:18]E: Failed to collect changes, error: 'hg init' command failed.
stderr: abort: repository . already exists!
[12:26:18] : Build finished
This is happening because the checkout directory already exists and is not being updated. I think the below solution should be all you need to get rid of this error.
In your TeamCity Configuration, redirect to the "Edit project build configurations" tab where you have set this build configuration.
In your build configuration click on the VCS tab on the left which will show you the attached VCS repositories to that configuration.
On this page there is a small CheckBox which says something like "clean all files before checkout/build" tick this and run your build and it should delete all the existing instances of the repository which was pulled down and download it again.
I have had a similar issue to this and it was driving me crazy. It was happening on two different fresh instances of TeamCity v9.1.1.
In the end I installed a fresh version of v9.0.4 and it worked successfully each time.
I plan to upgrade the instance to v9.1.1 today and see if the breaks. So it looks as though it may be an issue with TC itself.
Related
I am using deployer (from deployer.org) to deploy Laravel and Magento 2 sites. From what I understand, it should deploy the .git folder also to a server. But for my configuration it does not do it somehow.
How can I make sure the git repository is also deployed and is available on the server after a deploy?
To make clear what the issue is, steps to reproduce (for me).
Deploy to server with deployer (dep deploy)
Login to server with SSH
Go to project directory
Typ in git status
Expected result:
app#e1a372088c46 ~/application (master)$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean`
Actual result
app#app:~/public_html/application$ git status
fatal: not a git repository (or any parent up to mount point /)
I am currently installaing a pipeline for my Visual Studio projects with Jenkins (on Windows).
I installed the Git Bash and Jenkins successfully, but when I generate a new Jenkins project I need to give a Repository URL. I entered the path to my project and got the following message:
Failed to connect to repository : Error performing command: git.exe
ls-remote -h file:///Users/myusername/Documents/Visual Studio
2015/Projects/QtTestApplication HEAD
I already searched for a solution and changed the user from Jenkins to the admin:
Jenkins configuration of git plugin
I double-checked the userchange in the Jenkins systeminformations (it's really running on the admin).
However i still get the same error as before and I'm not quite sure what to enter in this form.
I already tried "escaping" the whitespaces like this:
Failed to connect to repository : Error performing command: git.exe
ls-remote -h file:///Users/myusername/Documents/Visual\ Studio\
2015/Projects/QtTestApplication HEAD
EDIT: Solution Part 1
I found out, that git was not found by Jenkins and that i had to add it manually to it (edit the PATH variable).
We have a team city server installed on a server named pluto. It's a Windows Server machine. There is a build agent on Pluto used to do VS related builds.
We have another build agent connected to this TeamCity server instance called YOSX, a build agent that is running on Mac mini Yosemite.
I've created a build to build a solution on YOSX with rake script. As a VCS Root Checkout option I've selected Automatically on Agent.
Ok, I am expecting that perforce p4 app will be called by TC agent on YOSX machine, but when I run a build, I get an error:
Collecting changes in 1 VCS root (2s)
[Collecting changes in 1 VCS root] VCS Root details
[VCS Root details] "eyeleo.mac.dev" {instance id=98, parent internal id=31, parent id=Desktop_EyeLeoMac_EyeleoMacDev, description: "perforce: p4.radacode.net:1666: perforce stream: '//EyeLeo.Mac/dev'"}
Failed to collect changes, error: Unable to find P4 command-line client at path '//Applications/p4' on pluto for user PLUTO$
Why is trying to checkout on pluto with user $PLUTO while I specifically set it to checkout on build agent's machine.
P.S. Yes, I've set the build requirements so that the build configuration in question is only compatible with YOSX build agent.
The server does not try to checkout the sources, but it still collects the information about changelists: modified files, commit messages etc.
This information will be used to display diffs, relevant issues, to track possible causes of test failures.
Please, install p4 on the PLUTO as well.
In my case p4 file on YOSX (build agent machine) was in PATH, but didn't have execute permissions. chmod +x p4 solved the puzzle.
when I run git tfs fetch there is no output. It doesn't seem to be pulling any new changesets from the tfs server. I then ran git tfs fetch -d and got the following output:
C:\projects\Infinity>git tfs fetch -d
Command run:git tfs fetch -d
No authors file used.
git-tfs version 0.19.2.0 (TFS client library 12.0.0.0 (MS)) (32-bit)
Fetching from TFS remote default
git command: Starting process: git log --no-color --pretty=medium refs/remotes/tfs/default --
git command time: [00:00:00.0330000] log --no-color --pretty=medium refs/remotes/tfs/default --
git command: Starting process: git log --no-color --pretty=medium refs/remotes/tfs/default..HEAD --
git command time: [00:00:00.0210000] log --no-color --pretty=medium refs/remotes/tfs/default..HEAD --
info: refs/remotes/tfs/default: Getting changesets from 60 to current ...
Cleaning...
CleanupWorkspaceDirectory: Could not find a part of the path 'C:\projects\Infinity\.git\tfs\default\workspace'.
the first thing that I'm not understanding is that the line ...Getting changesets from 60 to current ... The TFS repo is currently on changeset 59, and when I cloned the repo, it was on changeset 57. So on a fetch, I SHOULD be getting changesets 58 to current...
the second thing is the last error it gives me. Can anyone explain what is going on with the CleanupWorkspaceDirectory error?
EDIT:
One other thing I forgot to mention is that I have added another git remote to repository, and I have merged what's in refs/remotes/tfs/default with my branch that I have retrieved from the git repository. Not sure if that caused something in git-tfs to break...
the first thing that I'm not understanding is that the line ...Getting changesets from 60 to current ... The TFS repo is currently on changeset 59, and when I cloned the repo, it was on changeset 57. So on a fetch, I SHOULD be getting changesets 58 to current...
I don't have enough data to understand exaclty where your problem come from but I will try to give you enough understanding to let you solve it yourself...
The line Getting changesets from 60 to current ... tell you that in the 'default' remote, the last changeset found is the 59 and that git-tfs is asking to tfs the changesets from 60 to the last to see if there is changes in the 'default' remote path (for exemple $/project/trunk). If there is no changes in this tfs path, no commit will be created.
So your problem could come from 3 things :
changes have been made in your other tfs path (managed by your other tfs remote). Then you should either fetch from all your remote with git tfs fetch -all or checkout your other branch and use git tfs fetch -I (that automatically get the good remote) or git tfs fetch -i idOfYourOtherRemote (if you want to specify yourself the remote to use)
you have messed something with the git-tfs metadata that broke git-tfs (perhaps during your merge). Be sure that only commits created from tfs changeset contains metadata git-tfs-id:[http://server:8080/tfs/teamCollection/]$/.../;Cxxin the commit message. These metadata are important for git-tfs and should not be modified or added to normal commit not fetched from tfs.
(less probable) the commits from tfs has already been fetch by someone else in another git repository from where you have fetch. And the commits have been found already in your repository and not fetched again. But in this case, you should see them in the 'default' remote history...
One other thing I forgot to mention is that I have added another git remote to repository, and I have merged what's in refs/remotes/tfs/default with my branch that I have retrieved from the git repository. Not sure if that caused something in git-tfs to break..
perhaps. let's check your metadata...
the second thing is the last error it gives me. Can anyone explain what is going on with the CleanupWorkspaceDirectory error?
That's not a problem. During cleanup (after all the important work was done) , git-tfs try to delete the temporary workspace directory. Because you fetched no changesets, the directory is not created and can't be found.
Which is the correct installation directory for Jenkins to use? Here are the options I have tried and the results I have seen.
C:\Git\bin\git.exe
C:\Git\cmd\git
same as above
C:\Git\cmd\gitk.cmd
If I continue and ask the job to build here is the console output.
Started by an SCM change
Building in workspace C:\Jenkins\workspace\git_test
Checkout:git_test / C:\Jenkins\workspace\git_test - hudson.remoting.LocalChannel#12f2468
Using strategy: Default
Cloning the remote Git repository
Cloning repository ssh:///jenkins#xxxx.yyyyyyyyy.com:test.git
git --version
Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information
Fetching upstream changes from origin
Seen 0 remote branches
No candidate revisions
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
Finished: FAILURE
Since they all result in one error or another its not clear which one is correct.
This is not a problem with git not being found but that putty has not yet been told that it can trust the ssh-key presented by the repository sshd server.
Run a manual git command first on the Jenkins server, so you can say yes to accept the host key, and then try again.