I have the following set-up:
TeamCity server running on one machine
TeamCity agent on a separate machine, connected via VPN to source control (TFS).
The VPN is a bit tricky to set up to run as a service so can't/don't want to set it up on the server as well. Rather, I was hoping to have everything go through that agent.
The build server fails while collecting sources, it appears it's trying to figure out what changes were performed in TFS (but it can't find the TFS host since it's not on that VPN). The build is set to check out the sources only on the agent.
I'm afraid the answer is obvious, but couldn't find any documentation confirming this...Is it possible to have such a setup? Or does the build server need access to the TFS repo to check for changes and trigger builds?
The TeamCity server will still require access to the VCS root to evaluate the current revision and changeset details.
It's important to note the additional side-effects of agent side checkout as well. See VCS Checkout Mode in the TeamCity docs for more information (note the 2nd line).
Related
My team has using TeamCity to automate some tiresome maintenance tasks, and over time, we've found we want to re-use common pieces, so we've got some common functions in a repository on Bitbucket.
For better or for worse, our Bitbucket has a daily backup/maintenance period that, when active, blocks all of our builds from running with the following error:
Failed to collect changes ... Bitbucket is currently unavailable
I've looked at the various checkout modes, though we're generally limited to checking out files on the server (Rather than agent). I had figured that if the files are checked out to the server, then if Bitbucket were unavailable, there would be some way to fall back on "Whatever is already there". Especially as we don't have Clean build checked.
Is there some way that we can fall back on whatever is already checked out on the TeamCity server? Or do we need to set up some kind of redundancy?
Yes you can.
you need to simply build a project in a directory location of a teamcity machine and then call the run from that location instead.
You can have a build with No VCS at all. This build run will utilize the folder you mentioned instead of cloning a VCS.
I know little about this, but it has fallen to be at work to look into. I know a really tiny bit about TFS, and a little less than that about Team City, but do have access to both.
I have a Team City project that watches for commits to a TFS repo. When someone checks in files, TeamCity fetches them, then builds the project and publishes it via web deploy to our 'Dev' environment. This process is much less automated for higher grade environments like UAT etc.
Now, suddenly about two weeks ago, someone changed something, and when do a build in TeamCity I get two error messages. The first seems more introductory, that there has been a problem:
Failed to collect changes, error: Failed to get current version of TFS
root. TF400324: Team Foundation services are not available from server
applogix-projects.visualstudio.com\DefaultCollection. Technical
information (for administrator): The remote name could not be
resolved: 'applogix-projects.visualstudio.com'
The second error message, displayed on the same screen as the first, is slightly more technical, and even includes a fairly verbose stack trace, which I will omit until clearly necessary. The 2nd message:
Failed for the root '"Hollard - MLAM - Web" {instance id=4, parent
internal id=1, parent id=HollardMlamWeb_HollardMlamWeb, description:
"tfs: https://applogix-projects.visualstudio.com/DefaultCollection
$/Hollard - MLAM/HollardMLAM/Hollard.MLAM"}: Failed to get current
version of TFS root. TF400324: Team Foundation services are not
available from server
applogix-projects.visualstudio.com\DefaultCollection. Technical
information (for administrator): The remote name could not be
resolved: 'applogix-projects.visualstudio.com'
Those remove names that cannot be resolved within Team City, e.g. applogix-projects.visualstudio.com\DefaultCollection resolves fine when I paste it into a browser, and it directs me to our Visual Studio Online location for the project.
What I would appreciate as an answer here is an overview how the TFS fetch and TC build basically occur, and then some settings in TeamCity and or VS Online TFS that could be causing something like this.
It might be worth noting that if I pull the 'official' publish profile for Dev, and manually straight from VS Publish wizard, the app builds OK is well deployed to the Dev environment.
You need to check VCS settings in your teamcity build. Follow below steps:
Go to Edit Configuraton settings
Click on Version Control Settings
Check TFS URL and other settings
Check Configuring VCS Roots for more details.
If the credentials are incorrect then Visual Studio Online will report that it does not exists to prevent hackers.
Tge most likely issue is that the credentials are invalid. You should check that the user still exists and has the correct permission. You may have to use the "alternative credentials" from a users profile.
You can use the TFS Credential Viewer to get master unattended credentials for your VSO account, however these are the keys to the kingdom, so protect them.
I am using TeamCity 8.1.3 and have one task in the build queue and compatible enabled agent.
In "Build Queue" teamcity says that task "Can run on" - "2 agents"
Both agents are idle.
I tried to reinstall teamcity, reinstall buildAgent and install agent on another machine.
Tried to run agent as root. I read all agent logs and didn't find any errors; only warnings for not installed VCS tools (i need only git and its installed - no warning for it).
Why wont the agent run my task?
If the VCS tools aren't installed then TeamCity can't pull down your code and run the agent.
From the TeamCity documentation http://confluence.jetbrains.com/display/TCD8/Git+(JetBrains):
Git support in TeamCity is implemented as a plugin. Git needs to be installed on the server machine and, if the agent-side checkout is used, on the agents.
and
[Build configuration] will run only on the agents where git was detected or specified in the agent properties.
So you need install git.
This page covers installation instructions for Windows, Linux and Mac: http://git-scm.com/book/en/Getting-Started-Installing-Git. This SO post discusses installation as well: Git for beginners: The definitive practical guide
I can see two possible reasons
One of the implicit requirements not fulfilled. You need to check the enqueued build info for this, it tells why exactly the build is in the queue with compatible agents but not running. Examples can be: limitation on simultaneous builds in build or template configuration, shared resources unavailable etc. This would be listed in the little popup next to the enqueued build label
I've seen this happening when a requirement wasnt fulfilled initially (I had build configuration limited to 1 build at a time) when the build was enqueued, then it was corrected but the queue cached this requirement. Re-enqueuing the build sorted that.
Hover by mouse cursor to your VCS engine (e.g. git) and maybe you'll see there this message:
Changes have not been collected yet
In that case check performance of your TC and vcs server. (this I just guess from the message)
I work for a fairly new web development company and we are currently testing subversion installations to implement a versioning system. One of the features we need the versioning system to perform is to update the development server with an edited file once it has been committed.
We would like to maintain one server for all of our SVN repositories, even though, due to system requirements, we need to maintain several separate development servers. I understand that the updates are fairly simple when the development server resides in the same location as SVN, but that is just not possible for us. So, we need to map separate network drives to the SVN server for each development server.
However, this errors on commit. Here is my working copy test directory, as referenced in the post-commit.bat file:
SET WORKING_COPY=Z:\testweb
This, however, results in an error...
post-commit hook failed (exit code 1) with output: svn: Error resolving case of 'Z:\testweb'
I'm sure this is because the server is not the same user as me and therefore does not have the share I need mapped to "Z" - I just have no idea how to work around this. Can anyone help?
UPDATE: The more I look in to these issues it appears that the real solution to the problem is to use a CI Server to accomplish what I am attempting to accomplish. I am currently looking in to TeamCity and what it might do for us.
Don't do this through a post-commit hook. If you ever manage to get the hook to succeed, you'll be causing the person who did the commit to wait until the update is complete. Instead, I recommend that you use Jenkins which is a continuous build engine.
It is possible that you don't have anything to build. After all, if you're using PHP or JavaScript, there's nothing to compile. However, you can still use Jenkins to do the update for you.
I can't get into the nitty-gritty detail hear, but one of the things you can do with Jenkins is redefine its working directory. You can do this by clicking on the Advanced button when you define a job, and it'll ask you where you want the working directory. In this case, you can specify your server's working directory.
One of the things you can do with Jenkins is have it automatically run tests, or maybe do a bit smoother update. For example, you might have to restart your web server when you change a few files, or maybe you need to make sure that if you're changing 100 files, they all get changed at once, or your server isn't in a stable state. You could use Jenkins to do this too. And, if there are any problems, you can have Jenkins email the person who is responsible for the server that the server update failed.
Jenkins is easy to setup and use. You can download it and start up Jenkins in 10 minutes. Setting up a job in Jenkins might take you another 15 minutes if you had never seen Jenkins before and had no idea how it works.
We're currently using CruiseControl.NET as a continuous integration server for a number of ASP.NET web projects, but we're also evaluating TeamCity.
This is working great for our build server.
What we'd like to setup is a customer facing test server. I'm thinking that when we are happy for our latest development version to be released to the client for test, we could label it in SVN.
I'd then like a second build server to build this version ready for the client to see.
The question is this - is there any way to get either CruiseControl.NET or TeamCity to build only the latest labelled version of the code in a repository?
If anyone has any alternative suggestions, that'd also be greatly appreciated!
You could have a designated location or branch in your subversion repository e.g. \release then point the second TeamCity build server at that.
When your are happy with trunk then overwrite the existing location. The second build server will pick this up, build it, and even deploy it to a test server.
I don't think there's a way to do this directly in TeamCity. You can however configure your build trigger to filter on files and/or users. So, if you touch a given file to indicate release status in addition to or rather than labelling, you can use that.
The trigger filter could be, for example (untested):
+:/ReleaseVersion.cs