I'm in the process of setting up a proper CI environment and am currently evaluation TeamCity. (So my TeamCity experience is non-existent.).
I've performed a default install of TeamCity 5.0.1 Professional in a clean Windows XP (for now) VM.
I've created my project and pointed it to my source repository and queued up a build.
However, I don't see any Build Agents installed/available via the Team City web interface. I've checked and there is a 'Team City Build Agent' service installed and it's running. I've also reviewed the log files in the buildAgent folder and don't see anything that would lead me to an error.
Is there a step or concept that I'm missing here on getting the default Build Agent to become available to Team City? I'm not trying to do anything complicated with the build. (at this point, I just want to pull my source down from the repository)
I had exactly the same problem. After going through settings, reinstalling the agent etc, I found that the problem was rather simple - the TeamCity agent placed a wrong teamcity URL in it's property (and other paths as well).
Find the buildagent.properties file ( buildAgentInstallDir\conf\buildagent.properties), and you'll probably see that all of the lines have 'escape' characters in them (e.g. serverUrl=http://localhost:8090/ )
Modify the file to remove escape chars (i.e. links should be plain like: serverUrl=http://localhost:8090/ , env.TEAMCITY_JRE=C:\Program Files\TeamCity\BuildAgentInstalled\jre and similar)
Hope this helps...
If your server is running on a machine with multiple IP addresses, the agent may fail to identify the correct IP address. You can explicitly set the IP address in the buildAgent/conf/buildAgent.properties file. You should see a section that is optional to set the IP of the buildAgent and the IP of the Teamcity server. I recommend trying both.
Right after a clean install you should see one build agent - the local machine. I don't think this has anything to do with you even having to have a project defined. IMHO you something went wrong with the installation.
Filip
If you've changed the TeamCity server port in conf/server.xml like:
<Connector port="8222" protocol=".."/>
You should change the default agent configuration in buildAgent/conf/buildAgent.properties
serverUrl=http://SERVER-IP-HERE:8222/
Related
I have a fresh build server and need to setup jenkins there. So I created a first user on the Mac mini, and used that user to install Jenkins on the machine.
Jenkins then created another user (Jenkins) on the Mac Mini.
I thought that correct way to proceed is to login as that Jenkins user (with Admin rights) and prepare the build environment as this Jenkins user.
But I cant install Visual Studio for MAC, cant install SourceTree... bcs even though Jenkins has Admin rights, I am getting
"You do not have permissions to open the application 'Install Visual
Studio for Mac' contact your administrator..." message.
But as I said the Jenkins user is Admin user. So am I doing it wrong? What user should prepare all the build tools? And if it is supposed to be the first user I created (after booting the Mac mini for the 1st time), how do I let Jenkins use the apps then? When I tried doing this on my macbook, jenkins couldnt use some of the build tools, bcs apparently it did not have the permissions to do so.
So what is the correct way to set up a jenkins environment, so I can install whatever tools I need, and Jenkins can use these during builds/deploys?
Any help appreciated, all the guides about jenkins speak of jenkins user, but none gave me an idea what is the best way to set this all up.
My 2 cents.
I have not worked with MAC. So some of my assumptions may be wrong or suggestions may be not applicable to you.
I have set up Jenkins mostly on Linux and a couple of times on Windows. I used to install Jenkins using the RPM package which, upon installation, will create a 'jenkins' user and group.
For start/stop/restart, I always use 'sudo' since Jenkins is installed as a service.
Other build related tools like Java, Maven etc, I always make sure that Jenkins can access them and execute them. ie, I give execute privilege on those tools.
The JENKINS_HOME directory, I used to create a symbolic link from the default home directory to a file system with enough storage. I will do the same for Jenkins log file.
The benefit of having those Jenkins/tool files/directories as part of a custom defined directory structure is that I do not need to remember installation paths of each tool. ie, I have my Jenkins, maven, java, sonarQube everything under a directory I know. Even if I set up these tools in different servers, I will stick to the same directory structure.
My suggestions to you.
Setup build tools which are to be used/accessed from Jenkins, set them up with your 'first user' and give execute privilege to Jenkins user/group.
Create a directory 'ci' and link or place all tools inside. You can further have subdirectories for app - for binaries/installed files, data - for generated data like Jenkins_home, log - to keep log files of these tools.
ci/jenkins
ci/sourcetree
ci/apache-maven
Suggestion 2 is initially time-consuming but it will save a lot of your time as you use the tools on a daily basis.
I currently have a Bamboo task that invokes jspm install from my local app's node_modules installation of jspm but the registry is missing.
The task errors out with "Registry bitbucket not found"
I assume this is because it's installing jspm in the scope of just the task and from that viewpoint the registry is never instantiated.
This is a new issue for me though and just recently started happening after I installed bamboo as a service. Previously, I had set up the registry local to the machine and it seems to have picked it up.
I don't have a working state that I can really revert back to however.
Has anyone else experienced issues with jspm registries in CI server tasks?
Update 1: I stuck a little sanity check in there to execute node -e "console.log(process.env.LOCALAPPDATA || process.env.HOME || process.env.HOMEPATH)" since this is where it looks for the global config anyways and found that the variable that gets used here is not always the same. Sometimes it's my user home (desirable) and other times it's the system's home path (undesirable).
This is the part that's telling of what the issue is:
This is a new issue for me though and just recently started happening
after I installed bamboo as a service. Previously, I had set up the
registry local to the machine and it seems to have picked it up.
Checking what user it was set to use in the services revealed that it was configured to use the local system account which is incorrect. Changing to use the properly configured user account resolves the problem.
I have a build environment with multiple agents.
I would like to set up an Agent Requirement in my build that detects if certain software is installed. In some cases I can look in the env.Path for a particular string. But some software doesn't modify the Path.
I realize that after I install the software i could edit the BuildAgent.properties file to set a particular property, but I'd like it to be more automatic.
The specific instance is I have a build that uses MSDeploy to deploy websites, but it won't work if MSDeploy isn't installed. How can I specify in my build that I need an Agent that has MSDeploy installed?
You can build a simple agent plugin. Here are a few suggestions:
Extend AgentLifeCycleAdapter and implement agentInitialized method
Implement logic of detection the necessary application (for example based on some file existence) inside agentInitialized method
Use agent.getConfiguration().addConfigurationParameter() to report agent parameter to the server
If your detection logic can be implemented through file detection, you can use FileWatcher to monitor specific files and report parameters based on them even without restart of the agent
To my knowledge Agent Requirements work simply by validating either the existence of, or the value set in an Agent Parameter. As you say, this requires editing the <agent home>/conf/buildAgent.properties configuration file, either manually or in some automated way.
In terms of automation, you could take the approach of authoring a build configuration that acts as an agent bootstrapper; i.e. a build that runs on all agents (scheduled overnight / manually triggered) and maintains build agent parameters in the <agent home>/conf/buildAgent.properties file depending on certain conditions on the agent. Something like (pseudo):
if [ exists /path/to/MSDeploy ] then echo MSDeployExists to buildAgent.properties
This comes with a big disclaimer; I haven't tried this myself, and I believe that the agent will restart automatically based on changes to this file, so there may be issues with editing that file automatically. But it's a potential solution to maintaining your requirements in a centralised manner, and if it works then great. I use a similar approach to bootstrapping custom build scripts out to all agents to augment the already rich feature set in TeamCity.
I agree with the answer from SteveChapman. It is clear that you can test for environment variables (exits, contains, starts with, etc.). TeamCity is aware of versions of .NET installed on the agent (as well as Visual Studio, and VS SDKs). However, I can't find anything that would be equivalent to a "testpath" sort of capability.
The sure way to know is to add an agent parameter via the <agent home>/conf/buildAgent.properties configuration file.
I got Team Explorer Everywhere so we can use TFS on the Mac Mini we got to test Iphone apps. Since we're using XCode for phonegap, we need to use the commandline program and it is giving me a lot of grief.
What I've done so far (Listing out for anyone who stumbles on this so they can use it):
-Downloaded the trial (free)
-Set the path using PATH=$PATH\:/FOLDERLOCATION
-Accepted EULA and got trial product key... for command line program (tf eula/tf productkey -trial)
-Set up workspace:
tf workspace -new WORKSPACENAME -server:http://SERVERNAME:PORT/FILEPATH -comment:"WORKSPACENAME" && prompted for username -> domain -> password
-Trying to setup the folder path (Fixed):
tf workfold -map SERVERFOLDERPATH LOCALFOLDERPATH -collection:http://SERVERNAME:PORT/FILEPATH -workspace:WORKSPACENAME && prompted for username -> domain -> password
-Make sure I can check out/check in (On hold):...
The error I'm getting right now is "An argument error occurred: First free argument must be a server path." This is what I've been following ever since I got the path set, but I think the versions are different because mine doesn't seem to be set up the same. Any help at all would be appreciated, and I'll keep up with the post as I figure parts out because there doesn't seem to be much online that I can find on TFS on macs.
Update: As normal, I'm an idiot. Have to put the options at the end of the command and have to have the serverfolder path as the first thing after -map. Now I just need to figure out how to use the damn thing. I'll post any other questions I have and try to get all the correct commands up for the selfish reason of having them somewhere in case I forget them later.
Update 2: The mapping hasn't worked out as well as I'd hoped, it seems a combination of my unfamiliarity with Unix/Mac file systems and some settings being missing is keeping me from using 'tf get' to load all of the test data I was trying to get. I'm planning on trying again after I get the location of where my boss wants the data saved and after I can look into something that would save the workspace so it won't say that it can't find the map path every time...
It looks like you're setting up your workspace and some working folder mappings just fine, after the edit. If you're having problems doing a tf get after this, then there are some common problems that might be occurring. TFS workspaces can be a little bit opaque and having a better understanding of them can sometimes help you understand where the problem is:
Team Foundation Server requires a workspace to be configured before you can get files out of source control, edit them or check them back in. A workspace basically simply contains working folder mappings that map your local path(s) to server path(s).
Workspaces are stored on the server and are uniquely identified by your computer's hostname, your username and the workspace's name. A cache of this information for the local host is saved on the client. This implies:
If you remove a workspace on the server, your workstation will be unable to connect.
If you remove the cache, your local computer will not be able to identify the workspace based on working folder mappings until the cache is rebuilt (which happens every time you connect to the server.)
If you change your username or local workstation's name, you cannot access those workspaces.
(Note that very early versions of the Teamprise command line client had certain issues on Mac OS that made identifying the local workstation name difficult. This is fixed, however, in Team Explorer Everywhere.)
Because you can have multiple workspaces for a single server on a single workstation, you can't always simply provide server paths to tf commands, since server paths are ambiguous. ($/ exists in every workspace, for example.) So the command line client resolves paths based on the current working directory and/or the arguments provided. Meaning that you can run tf get foo.txt if you're in a working folder, or you can run tf get /tmp/foo.txt if /tmp is mapped.
One more point - the configuration data for Team Explorer Everywhere is shared between the TFS plug-in for Eclipse and the command line client. So if you're more comfortable using a GUI to set up your workspace(s), you can do that and then use the CLC as you see fit. You don't need to be a Java programmer to use Eclipse - simply download Eclipse and install the TFS plug-in for Eclipse into it, and select Window > Open Perspective > Team Foundation Server Exploring. After that, you'll have the full GUI Team Explorer experience and this perspective will be restored when you open Eclipse, so you won't even need to worry about the Java IDE bits if you don't want to.
I am managing a build lab and have several products/branches to provide service to and I would like my build machines not to be specialized to any one product/branch.
The scenario I would like to have is that souce and all tools needed to build it are checked into source control and just sync and build with some prep/env setup before hand via script.
This is very doable with Visual Studio and many other tools. Is it possible with Xcode? Has anyone gotten a scenario like this to work?
Some system components may need to be shared. Since this is such an atypical scenario, documentation will not be readily available. I would suggest asking on the Xcode-users mailing list that Apple maintains, as you may get a more certain answer.
I doubt if this possible. There are 2 possible ways I know of.
First, which we also follow in our project:
Source code for all projects in checked in the common repository.
A remote server is configured to point to this repository.
Remote server has XCode pre-installed. A pre-written scripts with steps including workspace cleanup, checkout fresh code, build the code, package the output is already feed into the remote server. Of these XCode related commands are using xcodebuild.
Remote server can be configured in 3 ways: a) Build the source code on every checkin, b) Build the source code triggered by user, c) Scheduled building of the source code.
Build results are emailed to the configured email addresses.
Second way is the continuous integration with MAC OS X server.
Just in case you found out the exact system config you are looking for, please post an answer here to enlighten us as well.