TeamCity is a CI server which allows us to integrate, run and test parallel builds simultaneously on different platforms and environments.
It has a lot of features, and offers great flexibility in terms defining multiple custom jobs to run different kinds of builds, but its not open-source.
Jenkins is open-source and is much more prevalent in the industry and has a very rich plugin-ecosystem which helps extend its capabilities.
Below are some points that are usually learnt the hard way and are not defined in any manual...
- Parameter values specified in the build settings anywhere are case sensitive. JDK!=jdk
- You can run multiple builds on TeamCity Agents for both Windows and Linux platforms, but each agent runs only one build at a time, and if you want to run multiple builds on the same agent, they get queue-ed and run sequentially rather than in-parallel simultaneously.
- Though you can always run builds in parallel (simultaneously) on different agents
- All paths that need to be specified in the build settings should be relative to the 'Build Checkout Directory', which can be found via %teamcity.build.checkoutDir%.
- All the project code-files get checked out from VCS/Git in the Build Checkout Dir, before actually starting the build execution.
- So if the checkout dir on a windows teamcity agent is actually C:\users\lokiagt\BuildAgent\work\989sds9898h989s\ then the complete path to the source of the project would be 'C:\users\lokiagt\BuildAgent\work\989sds9898h989s\cloud-bdd\'
- This is also the reason we should give all paths for reports/data/config relative to the Project Dir so that it can be easily accessed from CI boxes regardless of where it gets checked out to.
- Ensure to use \ for path on windows agents and / for linux agents.
- Use the publish artifacts feature in general settings for the build to publish any file/result/csv to be available after the build is complete. For example if the HTML results get generated in the folder cloud-bdd/reports/<build-name><build-no>, then we can direct teamcity to publish all artifacts in that directory by specifying its path like:
- cloud-bdd\reports\%system.teamcity.buildConfName%%system.build.number% => AutoResult
- AutoResult is the folder name which would be visible under the 'Artifacts' section of the Build and Global Build homepage under the 'blue-box-icon'.
- Properties used to filter agents for run
- teamcity.agent.jvm.os.name > Windows/Linux
- teamcity.agent.name > hostname of the agent
- env.JAVA_HOME > jdk/jre
- There are a lot of properties that can be used for example env.TEAMCITY_BUILDCONF_NAME returns the name of the build and env.BUILD_NUMBER returns the dynamic build number associated with that build.
- These can be called via System.getenv("env.TEAMCITY_BUILDCONF_NAME") and System.getenv("env.BUILD_NUMBER"). We use 'getenv' method as these are Environment Parameters for the Agent/Build.
- Installing the TeamCity Windows Agent -
- The server URL should not end with / it should be just hostname.domain.net. Also, giving just the hostname is enough, no need to give the domain if its in the same network.
- We can use \ [for windows] while specifying the absolute path in the agent.bat file. We may use / [for linux] for relative paths.
- The teamcity agent comes bundled with its own JRE so we should use that and not the system JDK/JRE because the local ones are not used in the agent.bat files. Hence, no need to add TEAMCITY_JRE as an Environment Parameter.
- The parameter names given in the wrapper.conf file of the agent is nothing but the -D flags similar to jvm/mvn coordinates.
- Flags for the jvm command should be specified like: jvm -DpathName=<path>
- Certificate errors are thrown up when the JRE versions are different on the agent client and the agent server like [jre8.121 and jre8.202]. Though online help suggest that the path to the cacerts.jks file should be in your Path variable and you should update the cacerts file there, its actually not needed because when you add the JAVA_HOME to your path, the cacerts file also gets added to the path as it is located under the security folder in JAVA_HOME folder as %JAVA_HOME%/jre/lib/security.
- To check if the certificate is present and installed in the correct location use this command:
- keytool -list -keystore %JAVA_HOME%/jre/lib/security/cacerts
- Do not install the teamcity agent on a client having QTP installed because the Environment Parameters of QTP would wreak havoc and not let it run at all. This would happen even if you removed all Env Parameters related to QTP, which is quite strange.
- Even if you are not able to run the agent as a windows service, you can run the agent.bat file which does the same thing.
- You can start and stop the agent service via agent.bat file via these option flags, given from the C:\BuildAgent\bin folder
.\agent.bat start and .\agent.bat stop
- Even though the default installation is supposed to be error free there could be lot of issues and errors in the agent.bat file that would have to be fixed before you could actually get it to run. Like providing the absolute path of the Log4J XML file, path of the cert file. Most of the times relative paths would not work so we would have to give absolute path in the jvm coordinates.
- Sample command to be run from the C:\BuildAgent\ dir with all paths relative to the BuildAgent\ dir:
- C:\BuildAgent\jre\bin\java.exe -ea -Xmx384m -Djava.security.debug=all -Dlog4j.configuration=file:..\conf\teamcity-agent-conf.xml -Dteamcity_logs=..\logs -Djavax.net.ssl.truststore=..\..\BuildAgentConf\cacerts.jks -Djavax.net.ssl.truststorePassword=changeit -classpath C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files (x86)\Python37-32\Scripts\;<all other classpaths> -file ..\conf\buildAgent.properties -launcher.version=61544
- Always use the old CMD window and never the powershell window as it does not work well with relative paths.
- You can view the logs for the agent starter, wrapper and agent connection, under the different log files under C:\BuildAgent\logs dir
