Установка teamcity + mariadb на linux ubuntu

Install and run on Windows

Run the downloaded file and follow the instructions of the TeamCity Setup wizard. The TeamCity web server and one build agent will be installed on the same machine.

During the installation, you can:

set the TeamCity Home Directory where TeamCity will be installed.
choose whether the TeamCity server and agent will run as Windows services
configure ports:
- Server port: is the default port. Note that it can be already occupied by other applications on your machine. If this port is already in use, you can change it during the installation. In the example below, we set the port to .
- Agent port: is the default for incoming connections from the server. If this port is already in use, you can set the property to a different value to change the port.

If you have installed TeamCity as a Windows service, follow the usual procedure of starting and stopping services. Otherwise, to start or stop the TeamCity server and one default agent at the same time, launch the script via a command line. The script is located in the directory.

to start the server and the default agent:

.\runAll.bat start
to stop the server and the default agent:

.\runAll.bat stop

Windows Docker Containers

Problems common to TeamCity Docker container images.

Since Windows 10 version 1803 with KB4340917 it’s possible to use port mapping from containers to localhost. For previous Windows versions it works for the non-localhost IP address associated with this machine and you can access a running application via the machine’s hostname or determine the IP address via the command. Note that the command may not show that the port is open on any IP address, while in fact it can work. This is also a known problem of Docker on Windows.
On Windows 10, the memory allocated per container is 1GB by default. To increase this value, use the following memory options:

docker run … -m 6GB —cpus=4 -e TEAMCITY_SERVER_MEM_OPTS=»-Xmx3g -XX:ReservedCodeCacheSize=450m»
On Windows 10 containers work via Hyper-V and may experience problems with network and other subsystems. To diagnose these problems, execute the following PowerShell script:

Invoke-WebRequest https://aka.ms/Debug-ContainerHost.ps1 -UseBasicParsing | Invoke-Expression
When starting a TeamCity server from a Windows Docker image, make sure to grant «Authenticated Users» the Full Control over the directories used as volumes. See the related issue.
When starting a Windows Docker container with the directory mapped as a volume to the container host, Git for Windows fails with a following error: «Invalid path ‘/ContainerMappedDirectories’: No such file or directory». The workaround is not to add as a volume.

To analyze the script output, refer to the following documents. If it shows that there are problems with the container network subsystem, try resetting it using the clean-up scripts.

More details on troubleshooting Docker for Windows are available in the Docker and Microsoft documentation.

SSL problems connecting MS SQL Server and TeamCity

Since MS SQL Server always establishes an SSL connection between the JDBC client (the TeamCity application) and the server, connection problems may occur (SQL exception: Connection reset).

Affected MS SQL versions

Any version prior to the ones listed below:

SQL Server 2012 Production version and later
SQL Server 2008 Service Pack 3 Cumulative Update 4
SQL Server 2008R2 Service Pack 1 Cumulative Update 6
SQL Server 2008R2 Service Pack 2

Cause: The problem is caused by the Java 1.6 update addressing this security vulnerability.

Solution: Microsoft SQL Server upgrade is recommended.

Workarounds: If Microsoft SQL Server upgrade is not possible for some reason, TeamCity can be set up to use older Microsoft SQL Server versions with the database connection still SSL- or TLS-encrypted.

Установите серверную среду

2.1 Установка среды Docker:

Из-за стены вам необходимо использовать внутренний сервис ускорения изображений. Здесь вы используете сервис ускорения изображений Alibaba Cloud, сервис ускорения изображений Alibaba Cloud. После входа в Alibaba Cloud выберите ->

2.1.1 Сначала установите Docker

После загрузки введите:

Проверьте, успешно ли установлена докер.

Затем настройте источник ускорения, здесь вы можете использовать команды, предоставляемые Alibaba Cloud, или вы можете использовать WinSCP, чтобы найти каталог / etc / docker для создания daemon.json.

xxxxxxx изменен на адрес, предоставленный Alibaba Cloud

Если он добавлен с помощью команд, пожалуйста, введите следующие команды соответственно

Затем перезапустите сервис докера

Окружение докера настроено

2.1 Установка среды TeamCity-Server

Вытащите официальный образ (немного большой, рекомендуется использовать тестирование облачного сервера, большая входящая пропускная способность, блокировка скорости загрузки)

появиться

Потяните успешно, затем запустите teamcity-server

Вышеуказанные результаты были успешными. Затем откройте порт 8111 на брандмауэре (в Интернете) и получите доступ: <ваш идентификатор>: 8111

Приведенная выше картина, кажется, построить успешно!

Нажмите кнопку , чтобы перейти к следующему шагу, выберите тип базы данных, которую вы подготовили, выберите MSSQL здесь, вам нужно скачать драйверы JDBC, нажмите кнопку , он загрузит

Заполните картинку выше, нажмите , подождите 3-10 минут, если есть ошибка, проверьте, правильно ли указаны ваши параметры!

После завершения появится соглашение. Потяните вниз, выберите Принять лицензионное соглашение и нажмите кнопку .

Затем появится страница для создания учетной записи, создайте учетную запись администратора самостоятельно, войдите в систему ~

На этом этапе, если проблем нет, настраивается среда teamcity-server.

2.2 Установка среды TeamCity-Agent

Существует teamcity-сервер, и для выполнения сборки и отправки необходим агент (аналогично платформе компиляции)

Первый шаг — вытащить изображение агента

Второй шаг — запустить контейнер

Лучше всего заполнить адрес внутренней сети (быстрая скорость установки и сэкономить трафик). Если нет локальной сети, необходимо указать адрес внешней сети

Обратите внимание!

И этот метод запуска поделится конфигурацией Docker и кешем с общим хостом Агента. В случае сомнений вы можете использовать другую команду.https://hub.docker.com/r/jetbrains/teamcity-agent/Пролистать

После выполнения вы можете использовать docker logs-f <CONTAINER-ID> для просмотра журнала запуска, CONTAINER-ID использовать docker ps для просмотра

Затем перейдите на страницу WEBUI сервера, выберите Агенты-> Неавторизованные

Просмотрите это! Тогда он появится в Связном!

Вот и все, вся среда TeamCity настроена! ! ! ! !

2.3. Установка ранчо-среды

Вытащите образ и разверните контейнер

Через 3-5 минут брандмауэр открывает порт 8080 и получает доступ к <ваш идентификатор>: 8080

Страница выше появляется, и среда ранчера установлена !!!

2.4.докер регистрация конфигурации среды

Изменить предыдущий daemon.json

Сохранить. 192.168.0.19 можно настроить как внешнюю сеть (проверено, есть проблемы), не забудьте открыть порт 5000!

Перезапустите докер

Обратите внимание, что перезапуск docker отключит контейнеры teamcity и rancher. Не забудьте перезапустить 3 контейнера (идентификатор запрашивается командой docker ps -a). Начать регистрацию

Начать регистрацию

На этом этапе создается среда ~! Далее идет реализация DevOps

TeamCity Setup for Cloud Integration

This section describes general steps required for cloud integration.

The requirements for a virtual machine/image to be used for TeamCity cloud integration:

The TeamCity agent must be correctly installed and configured to start on the machine startup.
to skip the update attempts on each agent connection to the server, make sure that the agent is up to date: start and wait for the update to complete. The agent state changes each time a plugin or tool is installed/updated/removed on the server.
the file can be left «as is». The , , and properties can be left empty or set to any value, they are ignored when TeamCity starts the instance unless otherwise specifically stated in the platform-specific documentation.

Provided these requirements are met, the usual TeamCity agent installation and cloud-provider image bundling procedures are applicable.

If you need the between the server and the agent machine to be secure, you will need to set up the agent machine to establish a secure tunnel (for example, VPN) to the server on boot so that the TeamCity agent receives data via the secure channel. Keep in mind that communication between TeamCity agent and server requires opening ports on both the agent and the server.

Installing Several Build Agents on the Same Machine

You can install several TeamCity agents on the same machine if the machine is capable of running several builds at the same time. However, we recommend running a single agent per (virtual) machine to minimize builds cross-influence and making builds more predictable. When installing several agents, it is recommended to install them under different OS users so that user-level resources (like Maven/Gradle/NuGet local artifact caches) do not conflict.

TeamCity treats all agents equally regardless of whether they are installed on the same or on different machines.When installing several TeamCity build agents on the same machine, consider the following:

The builds running on such agents should not conflict by any resource (common disk directories, OS processes, OS temp directories).
Depending on the hardware and the builds, you may experience degraded builds’ performance. Ensure there are no disk, memory, or CPU bottlenecks when several builds are run at the same time.
It is recommended to set up the agents to be run under different OS users

After having one agent installed, you can install additional agents by following the regular installation procedure (see an exception for the Windows service below), but make sure that:

The agents are installed in separate directories.
The agents have the distinctive and directories in the file.
Values for the and properties of are unique.
No builds running on the agents have the absolute checkout directory specified.

Make sure there are no build configurations with the absolute checkout directory specified (alternatively, make sure such build configurations have the «clean checkout» option enabled and they cannot be run in parallel).

Usually, for a new agent installation you can just copy the directory of the existing agent to a new place with the exception of its , , , and directories. Then, modify with the new , values. Clear (delete or remove the value) the property and make sure the and are relative/do not clash with another agent.

If you are installing a second build agent on Mac OS, see additional details .

If you use Windows installer to install additional agents and want to run the agent as a service, you will need to perform manual steps as installing second agent as a service on the same machine is not supported by the installer: the existing service is overwritten (see also a feature request).In order to install the second agent, it is recommended to install the second agent (using .zip agent distribution). You can use Windows agent installer and do not opt for service installation, but you will lose uninstall option for the initially installed agent this way.After the second agent is installed, register a new service for it as mentioned in the .

See also:

Concepts: Build Agent

Before Upgrade

Before upgrading TeamCity:

For a major upgrade, review what you will be getting in What’s New.
unless you are upgrading within bugfix releases of the same major version.
Download the new TeamCity version (see links to all released versions).
Carefully review the Upgrade Notes.
Consider probing the upgrade on a .
If you have non-bundled plugins installed, check plugin pages for compatibility with the new version and upgrade/uninstall the plugins if necessary.

To upgrade the server:

Back up the current TeamCity data including settings, database, and supplementary data. You will need the backup to roll back to the previous version in the unlikely event of the upgrade failure.

Slow download from TeamCity server

If you experience slow speed when downloading artifacts from TeamCity, try checking the speed on the server machine, downloading from localhost. If the speed is OK for the localhost, the issue can be in the network configuration or OS/hardware settings when combined with TeamCity (Tomcat) settings.

Make sure <TeamCity Home>\conf\server.xml file corresponds to the file included in TeamCity distribution (can be checked in .tar.gz distribution). If you have the following «Connector» node (ports numbers can be different):

change it to:

and restart TeamCity server.

Using Build Parameters in Build Configuration Settings

In most build configuration settings, you can use a reference to a build parameter instead of using the actual value. Before starting a build, TeamCity resolves all references with the available parameters. If there are references that cannot be resolved, they are left as is; a respective warning appears in the build log.

To reference a build parameter, use its name enclosed in percentage signs: for example, .

TeamCity considers a reference to a property any text that is enclosed in percentage symbols. If the property cannot be found in the build configuration, the reference becomes an implicit agent requirement and such build configuration can only be run on an agent with this property defined. The agent-defined value will be used in the build. If you want to prevent TeamCity from treating the text in the percentage signs as a reference to a property, use two percentage signs. Every occurrence of in the values where property references are supported will be replaced with before passing the value to the build. For example, if you want to pass into the build, change it to .

Using Build Parameters in Build Scripts

All build parameters starting with the prefix (environment variables) are passed into the build’s process environment (omitting the prefix).

All build parameters starting with prefix (system properties) are passed to the supported build script engines and can be referenced there by the property name, without the prefix. You can this prefix to access these properties in the TeamCity UI or, for example, in the Command Line runner. Note that this syntax will work in the build script (not in TeamCity settings):

For Ant, Maven, and NAnt, use .
For .NET, use . Note that MSBuild does not support names with dots (), so you need to replace with when using the property inside a build script. Note that the and commands do not support properties.
For Gradle, the TeamCity system properties can be accessed as Gradle properties (similar to the ones defined in the file) and are to be referenced as follows:

name allowed as a Groovy identifier (the property name does not contain dots):

println «Custom user property value is $\{customUserProperty\}»

name not allowed as a Groovy identifier (the property name contains dots: for example, build.vcs.number.1): project.ext

When TeamCity starts a build process, the following precedence of the build parameters is used (those on top have higher priority):

parameters from the project- and agent-level build parameters file
predefined parameters
parameters defined in the Run Custom Build dialog
parameters defined in build configuration settings
parameters defined in a project (the parameters defined for a project will be inherited by all its subprojects and build configurations; if required, you can redefine them in a build configuration)
parameters defined in a template (if any)
parameters defined in the agent’s file
environment variables of the build agent process itself

The resultant set of parameters is also saved into a file which can be accessed by the build script. See the system property or environment variable description in Predefined Build Parameters for details.

Agent Directories

The agent consists of:

agent binaries (stored under , , and directories). The binaries can be automatically updated from the server to match the server version.
agent plugins and tools (stored under and directories). These are parts of agent binary installation and are managed by the agent itself, updating automatically whenever necessary from the TeamCity server.
agent configuration (stored under and directories). This is a unique piece of information defining the agent settings and behavior.
agent work directory (stored under the directory by default, configurable via agent configuration).
agent auxiliary data (stored under , , , directories). The data necessary during agent running.
agent logs (stored under directory): The directory storing internal agent logs that might be necessary for investigating agent issues.

Creating Build Configuration Pointing to Specific VCS

In the :

Click the button respective to your VCS: from GitHub.com, GitLab CE/EE, Bitbucket Cloud, Azure DevOps Services, or JetBrains Space.

Note that to be able to access the selected VCS, TeamCity needs to always have the connection parameters at its disposal. You can configure the connection preset in advance and select the target VCS server in the wizard, or let TeamCity redirect you to the Connections page right from the wizard. The connections settings of supported VCS providers are described here.
Verify the connection to the VCS.
TeamCity will propose the build configuration name. You can change it if needed.

For a Git repository, it will also autodetect the default branch. You have an option to change it now or later, in the VCS root settings. You can also change the branch specification: by default, TeamCity monitors all branches of the repository, but you can choose what exact branches to monitor by entering .

Click Proceed.
TeamCity will add a VCS build trigger and attempt to : Ant, NAnt, Gradle, Maven, MSBuild, Visual Studio solution files, PowerShell, Xcode project files, Rake, and IntelliJ IDEA projects. On the Auto-detected Build Steps page, select the step(s) to use in your build configuration. Click Use selected. You can then always add or edit steps manually.

Depending on the build configuration settings, TeamCity can suggest some additional configuration options. Review the suggested settings and configure the required ones.

Configuring Java

A TeamCity build agent is a Java application that requires JDK version 8-10 to work. OpenJDK 8 (for example, by AdoptOpenJDK) 1.8.0_161 or later, 32-bit is recommended. Oracle Java 8 is also supported.

A build agent contains two processes:

Agent Launcher – a Java process that launches the agent process
Agent – the main process for a Build Agent; runs as a child process for the agent launcher

The (Windows) TeamCity distribution comes bundled with OpenJDK 1.8.0_161.If you run a previous version of the TeamCity agent, you will need to repeat the agent installation to update the JVM.

Using x32 bit JDK (not JRE) is recommended. JDK is required for some build runners like IntelliJ IDEA Project, Java Inspections, and Duplicates. If you do not have Java builds, you can install JRE instead of JDK.Using of x64 bit Java is possible, but you might need to double the memory value for the main agent process (see Configuring Build Agent Startup Properties and alike for the server).

For the agent installation you need to install the appropriate Java version. Make it available via or available in one of the following places:

the directory
in the directory pointed to by the , or environment variables (check that you only have one of the variables defined).
if you plan to run the agent via Windows service, make sure to set the property in the file to a valid path to the Java executable

TeamCity First Start

When you launch TeamCity in a browser for the first time, it will prompt you to complete the installation:

Review the , where all the configuration information is stored. Click Proceed.
TeamCity stores the build history, users, build results, and some runtime data in an SQL database and allows you to select the database type.

For now, keep the default internal database. Click Proceed.

It will take some time for TeamCity to configure the necessary components.
On the next screen, accept the License Agreement to proceed with the launch. Click Continue.
TeamCity displays the Create Administrator Account page. Specify the administrator credentials and click Create Account.

You are signed in to TeamCity: now you can configure your user settings and create and run your first build.

Installing Several Build Agents on the Same Machine

TeamCity treats equally all agents no matter if they are installed on the same or on different machines. However, before installing several TeamCity build agents on the same machine, please consider the following:

Builds running on such agents should not conflict by any resource (common disk directories, OS processes, OS temp directories).
Depending on the hardware and the builds you may experience degraded builds’ performance. Ensure there are no disk, memory, or CPU bottlenecks when several builds are run at the same time.

After having one agent installed, you can install additional agents by following the regular installation procedure (see exception for the Windows service below), but make sure that:

The agents are installed in the separate directories.
The agents have distinctive and directories in file.
Values for and properties of are unique.
No builds running on the agents have absolute checkout directory specified.

Moreover, make sure you don’t have build configurations with absolute checkout directory specified (alternatively, make sure such build configurations have «clean checkout» option enabled and they cannot be run in parallel).

Usually, for a new agent installation you can just copy the directory of existing agent to a new place with the exception of its «temp», «work», «logs» and «system» directories. Then, modify with a new «name» and «ownPort» values. Please also clear (delete or remove value) for «authorizationToken» property.

Important Agent Files and Directories

/bin
- — batch script to start/stop the build agent from the console under Windows.
- — shell script to start/stop the build agent under Linux/Unix.
- — batch file to install the build agent as a Windows service. See also .
- — starts the build agent using the installed build agent service.
- — stops the installed build agent service.
- — batch file to uninstall the currently installed build agent Windows service.
/conf/: this directory contains all configuration files for the build agent.
- — main configuration file. This file is generated by the TeamCity server installer and build agent installer.
- — sample configuration file. You can rename it to to create an initial agent configuration file.
- — build agent logging settings. For details, refer to comments inside the file or to the log4j manual.
/launcher/conf/
- — sample configuration file to be used as a template for creating the original configuration.
- — current build agent Windows service configuration. This is a Java Service Wrapper configuration java properties file. For details, see comments inside the file or Java Service Wrapper documentation.
/logs
- — log of the build agent launcher.
- — main build agent log.
- — log of the Java Service Wrapper. Available only if the build agent is running as a Windows service.
- — log from the build.
- — log from the build agent upgrade process.
- — agent-side checkout logs.
/system

.artifacts_cache — cache for all build’s artifacts; can be configured.

/temp: temporary directory; the path can be overridden in the file.
- — temporary directory that is used by the build agent to store build-related files during the build. Is cleaned after each build.
- — temporary directory that is set as the default temp directory for the build process and is cleaned after each build
- — temporary directory that is used by the build agent for its own temporary files. Is cleaned on the agent restart.