I'm planning to migrate my teamcity server onto a new physical location. The process is pretty straight forward, export the database, install a vanilla teamcity server and import the database via maintaindb.sh.
Since i have a large installation I decided to backup only server settings, projects and builds configurations, plugins. My point was that I can manually move build logs and artifacts later (i'd rather not try to restore from a 500GB zip file). However after importing the backup I was unable to see any build agents in the agent pool.
Any ideas? Do you have to install each build agent from scratch just because the server got migrated to a new location? Do you just have to point the agents to the new server and that's it (and if so why does the agent pool on the server seem empty)
Thanks,
If you are changing the servers URL in your migration, which from your question I am assuming that you are, then you will need to edit each build agent's properties.
In your ~TeamCity\Install\buildAgent\conf, you will have a buildAgent.properties file. You need to modify this file to point to your new Teamcity location via the serverURL value. Then you will want to restart the build agent server, and authorize and enable the build agent from your Teamcity interface.
There is an extremely brief explanation of this here at the bottom of the "Move TeamCity Installation to a New Machine" section.
And to answer your question as to why the agent pool seems empty - it is because the agent is not looking for the server at it's new location.
Related
I have 2 separate Teamcity web application instances running on separate servers accessing the same git repository.
This seems to be causing issues with the VCS root configuration.
The specific error message is:
Error collecting changes for VCS repository ... 'git fetch' command failed... 301 Moved permanently
I get this message for every build configuration with every teamcity project in my installation.
I must maintain 2 separate teamcity application instances on different servers - one that builds Microsoft Windows software artifacts and the other that build Linux based artifacts.
The only workaround that I currently have for this problem is to delete the VCS root and set it up again - only to discover that the next day the problem is back.
I can't keep doing this forever - there must be a better way to address this.
Does anyone know how?
After working with Jetbrains support, they root caused the issue to the use of http:// in the github URL instead of https://.
So, IOW, when you specify a github repository URL, you must use https:// in a temmcity VCS root configuration.
Since we had moved TFS Application Tier to a different server the TFS builds have stopped working. Whenever I try to start a build it fails with the following error:
TF215097: An error occurred while initializing a build for build
definition \My\Build: TF214007: No build was found with the URI
vstfs:///Build/Build/8320. Either the URI does not exist, or NT
AUTHORITY\NETWORK SERVICE does not have permission to access it.
The set up is following:
Server TFSAT contains the TFS Application Tier and a build controller. Server TFSBUILD contains a build agent and a build service running under NT AUTHORITY\NetworkService account. The build agent uses build controller on server TFSAT.
I have already triple-checked that the network service account TFSBUILD$ belongs to the team project collection's group Project Collection Build Service Accounts.
Also I have already tried to open the URL vstfs:///Build/Build/8320 on the server TFSBUILD which results in starting a Visual Studio instance and giving the error: The provided argument vstfs:///Build/Build/8320 must contain a query parameter named url which contains the full qualified URL to the Team Project Collection.
I have also tried to create a fresh new build and run this one - the same issue.
Has anyone got a clue what might be set up wrongly? I could not find any additional permission that should be granted to the build service account (standard network service account in my case).
Please notice that I am quite a newbie when it comes to setting up TFS. Thank you in advance for any hints.
First, please make sure you have followed the correct operation in Move Team Foundation Server from one environment to another.
To narrow down the issue you can:
Try to restart the build service on the build controller and
agent and queue another build.
Use another build account not NT AUTHORITY\NETWORK SERVICE and try
again.
If you still get the error, try to use below workaround: delete the old build control and agent. Create a new one. Note: you may have to edit all build definitions to point to the new control and agent.
We've been experimenting with Octopus Deploy on a development PC and now want to transfer the environment we've created onto our main Octopus Deploy server (which is used by other teams and already has a few environment set up on it).
So we would like to backup/restore this one environment. However, it looks like Octopus only allows you to backup/restore the entire database.
Is it possible to move a single environment from one Octopus server to another using backup/restore or another means?
What worked for me was simply doing the following in order:
Shutting down Octopus service so that no transaction going through.
Copy the raven database (usually stored in Program Files\Data) to your new server.
Install the new Octopus server and during the setup, in the Storage Tab, specify the location of your data location copied in the second step above.
The Octopus developer, Paul, mentions the great thing about RavenDB is the installation. It requires no services running like SQL. It's just a copy paste of the data itself and great for installation and portability.
There's currently no way to backup/restore just part of the database - you'd need to restore a full backup, and then delete the information you don't need.
Octopus 2.0 (which is now a public beta) has a comprehensive REST API so it would be possible to use that API to fetch a subset of information and import it to your new Octopus server.
Rather than having teamcity log onto the gitolite server several tens of thousands of times each day - and also sitting around waiting for the poll to happen (or starting it manually).
It would be nice if it was possible to set it up gitolite hooks that inform TeamCity that the repository has changed.
Is such a configuration possible with TeamCity and gitolite?
I know Jenkins has a github plugin that works nicely - I use that setup for some Minecraft CI I am running privately.
One way would be to gitolite (through a VREF hook) to call TeamCity through its REST API, in order to launch a build through web request.
You just need to make web request to the following URL:
http://YOURSERVER/httpAuth/action.html?add2Queue=btId
, where btId is build type Id – unique identifier for each build configuration.
To get it, you can just look for it in browser address bar, when clicking on build configuration, or use TeamCity REST API for details.
The OP Morten Nilsen didn't need a VREF:
add a file "post-receive" to .gitolite/hooks/common and
run gitolite setup --hooks-only
I want to setup two Hudson Masters on the same Hardware. This will make administering Hudson easier, since both servers are used by two different (and independent) teams.
So far I tried to install one server as a service. I verified the installation and it is running ok. I than copied the installation into another path and changed the service information (different service Name and description) and the httpPort. I then create the service, once using sc.exe create and once using hudson.exe install. In both cases the server started. However, the configuration page acted goofy. So this approach is either not working at all or I missed another configuration file.
Does anyone has an idea how to accomplish this?
I tried the same approach as documented in the question but avoided the copying of the original installation. So I created two folders and put a copy of hudson.war in it. Then I performed the following steps for both folders.
Start Hudson with java -jar hudson.war
Installed Hudson as a service using the web UI
went into the Hudson Base Dir and ran hudson uninstall
modified the port and the Service information in hudson.xml
installed the service through command line hudson install
Now I have two services and the first quick test looks promising.
May I suggest:
run two instances of Tomcat
have each Tomcat running on its own HTTP port
deploy HUDSON.WAR in each Tomcat
set CATALINA_OPTS for each Tomcat to point to a different HUDSON_HOME