Configuring Connections
TeamCity allows storing presets of connections to external services. You can reuse these presets in various places on the server: when creating projects, configuring notifications, integrating with issue trackers, and more. This article gives instructions on how to add each type of connection.
To add a connection, go the target project's settings, open the Connections page, and click Add Connection. Select the connection type, set its Display name to distinguish it from the others, and configure it as described below.
When created, a connection can be used in all the nested subprojects of the current project. If you add a connection in the Root project, it will become available on the whole server.
If your TeamCity server is installed behind a proxy, it is important to ensure that this is reflected in the connection settings, if applicable. When configuring a callback URL for a connection, you need to specify all URLs by which the current server can be accessed.
After configuring the proxy, remember to also set the new address as the Server URL in Global Settings of TeamCity.
Azure DevOps
There are two types of Azure DevOps connections in TeamCity:
Azure DevOps OAuth 2.0 allows signing in to TeamCity via an Azure DevOps Services account and creating TeamCity projects from Azure Git repositories.
Azure DevOps PAT allows creating TeamCity projects from Azure Git and TFVC repositories.
Azure DevOps OAuth 2.0 Connection
This type of connection supports only Azure DevOps Services. It uses the OAuth 2.0 protocol based on JWT tokens and requires creating a dedicated app in your Azure profile.
This connection can be used for authenticating users via Azure DevOps as well as creating projects and build configurations.
To configure an Azure DevOps OAuth 2.0 connection:
In Project Administration | Connections, click Add Connection.
Select Azure DevOps OAuth 2.0 as the connection type.
Ensure the Enable unique callback URL setting is enabled to generate a unique ID added to your callback URL. This setting bolsters the security of your setup by mitigating the risk of mix-up attacks: attacks utilizing malicious authorization servers that impersonate real auth servers to trick a victim client into leaking an authorization code (token). Using the
/oauth/azuredevops/rid:your-unique-id/accessToken.html
URL format ensures an attacker cannot hand-craft an address acknowledged by TeamCity.TeamCity will display the Callback URL and scopes required for registering an OAuth application in Azure DevOps.
Go to the Register Application page in Azure and create a new app using the provided parameters. When created, copy the app's ID and client secret.Go back to the connection form in TeamCity and enter the Azure DevOps Services URL, the new application ID, and client secret.
Specify the application scope that must be the same as the scope of the created Azure DevOps OAuth App.
Save the connection.
To activate the Azure DevOps Services authentication on your server, proceed to enabling the respective authentication module.
Azure DevOps PAT Connection
This type of connection uses personal access tokens. It allows creating a project from a Git or TFVC repository URL, creating an Azure DevOps VCS root, or integrating with the Azure Board Work Items tracker.
To configure an Azure DevOps PAT connection:
In Project Administration | Connections, click Add Connection.
Select Azure DevOps PAT as the connection type.
The page that opens provides the parameters to be used when connecting TeamCity to Azure DevOps Services.
Log in to your Azure DevOps Services account to create a personal access token with All scopes as described in the Microsoft documentation.
Continue configuring the connection in TeamCity: on the Add Connection page that is open, specify
the server URL in the
https://{account}.visualstudio.com
format or your Azure DevOps Server ashttps://{server}:8080/tfs/
your personal access token
Save the connection settings.
The connection is configured, and now a small Azure DevOps Services icon becomes active in several places where a repository URL can be specified: create project from URL, create VCS root from URL, create Azure DevOps Server VCS root, create Azure Board Work Items tracker. Click the icon, log in to Azure DevOps Services and authorize TeamCity. TeamCity will be granted full access to all the resources that are available to you.
When configuring Commit Status Publisher for Git repositories hosted in TFS/VSTS, the personal access token can be filled out automatically if a VSTS project connection is configured.
Bitbucket Cloud
A connection to Bitbucket Cloud can be used to:
Create a project from Bitbucket URL.
Create a VCS root from URL.
Create a Mercurial VCS root.
Integrate with a Bitbucket Cloud issue tracker.
Enable Bitbucket Cloud authentication.
The Bitbucket Cloud connection form provides multiple parameters. You need to use them for creating a new OAuth consumer in Bitbucket.
After the consumer is created:
Copy its key and secret.
Go back to the connection form in TeamCity.
Paste the key and secret.
Save the connection.
A Bitbucket icon will become active in several places where a repository URL can be specified. Click it to authorize TeamCity in your Bitbucket profile. TeamCity will be granted access to your repositories. If you configure multiple Bitbucket connections, the server URL will be displayed next to each icon, so it is easier to distinguish the server in use.
Bitbucket Server and Data Center
Integration with Bitbucket Server and Data Center currently allows you to:
create a VCS root from URL
To allow TeamCity to access Bitbucket data, you need to create an incoming application link in Bitbucket to grant TeamCity required permissions.
Create a new connection and choose the "Bitbucket Server / Data Center" option.
Ensure the Enable unique redirect URL setting is enabled to generate a unique ID added to your redirect URL. This setting bolsters the security of your setup by mitigating the risk of mix-up attacks: attacks utilizing malicious authorization servers that impersonate real auth servers to trick a victim client into leaking an authorization code (token). Using the
/oauth/bitbucketserver/rid:your_unique_id/accessToken.html
URL format ensures an attacker cannot hand-craft an address acknowledged by TeamCity.In a separate browser tab, go to the Bitbucket "Administration | Application Links" page.
Create a new application link with the following parameters:
Application type: External application
Direction: Incoming
Redirect URL: <copy URL from the TeamCity new connection tab>
Application permissions: tick "Write" under "Repositories"
Once the application link is ready, Bitbucket will generate the "Client ID" and "Client Secret" values. Copy these values and paste them into corresponding fields on the TeamCity new connection tab.
Save the connection in TeamCity.
GitHub
TeamCity allows you to create connections to both regular GitHub.com instances and GitHub Enterprise.
A connection to GitHub can be used to:
Create a project from GitHub URL.
Create a VCS root from URL.
Create a Git VCS root.
Integrate with a GitHub issue tracker.
Enable GitHub.com and GitHub Enterprise authentication.
Provide access tokens for the Commit Status Publiser and Pull Requests build features.
Connections via GitHub Apps can be used to configure webhooks that notify the TeamCity server about changes.
Depending on your needs, you can create connections to GitHub that operate via GitHub Apps or GitHub OAuth Applications.
- GitHub App
A GitHub App is an integration that allows third-party services such as TeamCity to connect to GitHub repositories without the necessity to keep a "service" user account. Compared to GitHub OAuth applications, GitHub Apps boast fine-grained permissions and grant you more control over which repositories the app can access.See this article for more information: Differences between GitHub Apps and OAuth Apps.
In addition, configuration created via GitHub App connections can employ GitHub Checks Webhook triggers that replace the traditional combo of VCS trigger and Commit Status Publisher build feature.
If you do not already have a suitable GitHub App, you can allow TeamCity to register it and create a connection that employs this new app in one go. TeamCity uses manifests to register new GitHub Apps.
Go to Project Settings | Connections and click Add Connection.
Choose GitHub App from the drop-down menu (regardless of whether you need to connect to regular GitHub or GitHub Enterprise).
Select the Automatic creation mode to allow TeamCity to register a GitHub App from a manifest.
Specify the URL of your GitHub server (without "/username") and choose whether you want this app to send post-commit hooks and/or have access to your organization.
If the new GitHub App should provide access to organization repos, switch the Owner setting to Organization and enter the organization name in the corresponding field.
Follow instructions on your screen to log into your GitHub account, authorize TeamCity to register an app, and install it to your personal and/or organization account.
To manually create a new GitHub App and configure a TeamCity connection that uses this app:
Go to Project Settings | Connections and click Add Connection.
Choose GitHub App from the drop-down menu (regardless of whether you need to connect to regular GitHub or GitHub Enterprise).
Switch the connection's creation mode to Manual.
Ensure the Enable unique callback URL setting is enabled to generate a unique ID added to your callback URL. This setting bolsters the security of your setup by mitigating the risk of mix-up attacks: attacks utilizing malicious authorization servers that impersonate real auth servers to trick a victim client into leaking an authorization code (token). Using the
/oauth/githubapp/rid:your-unique-id/accessToken.html
URL format ensures an attacker cannot hand-craft an address acknowledged by TeamCity.In a separate browser tab, navigate to your GitHub account and follow instructions from the TeamCity connection description to create a new app. Note that GitHub will generate a private key in the process — save this
.private-key.pem
file in the secure location.Open the general settings of your GitHub App. Copy required values (App ID, client ID, client secret) and paste them to the TeamCity dialog.
If you have a GitHub App webhook configured, set its secret and copy the same value to the Webhook secret field. GitHub can use this webhook to notify the TeamCity server it should scan a repository for changes when they occur, instead of letting the server to constantly poll GitHub for changes. See also: Configuring VCS Post-Commit Hooks.
Enter the Owner URL — the link to a personal account or organization where this GitHub App is installed.
Upload the private key sent by GitHub.
Click Save to save your new connection.
- GitHub OAuth Application
OAuth Applications generate user access tokens and allow third-party services like TeamCity to perform actions on behalf of a user who authorized these services.
To create a TeamCity connection that utilizes a GitHub OAuth Application:
Go to Project Settings | Connections and click Add Connection.
Choose GitHub.com or GitHub Enterprise depending on which version you utilize.
If you do not already have a GitHub OAuth Application, follow TeamCity instructions to create a new one.
Copy the client ID and secret from OAuth Application's settings and paste them to the TeamCity dialog. For GitHub Enterprise you additionally need to paste the GitHub server URL.
Click Save to save your new connection.
Once a connection is successfully configured, the GitHub icon will become active in several places where a repository URL can be specified. Click it to authorize TeamCity in your GitHub profile. TeamCity will be granted full control of your private repositories and get the Write repository hooks permission. If you configure multiple GitHub integrations, the server URL will be displayed next to each icon, so it is easier to distinguish the server in use.
GitLab
There are two types of GitLab connections: GitLab.com for accounts hosted on the https://gitlab.com site, and GitLab CE/EE for accounts on a self-hosted GitLab Community Edition (CE) or Enterprise Edition (EE) server.
A connection to GitLab can be used to:
Create a project from GitLab URL.
Create a VCS root from URL.
Integrate with a GitLab issue tracker.
Enable GitLab.com authentication.
OAuth Applications generate user access tokens and allow third-party services like TeamCity to perform actions on behalf of a user who authorized these services.
To create a TeamCity connection that uses a GitLab OAuth Application:
Choose the project where you would like to create a new connection, noting that the connection will only be available to the chosen project and its subprojects.
Go to Project Settings | Connections and click Add Connection.
Choose GitLab.com or GitLab CE/EE.
For the GitLab CE/EE option, ensure the Enable unique redirect URL setting is enabled to generate a unique ID added to your redirect URL. This setting bolsters the security of your setup by mitigating the risk of mix-up attacks: attacks utilizing malicious authorization servers that impersonate real auth servers to trick a victim client into leaking an authorization code (token). Using the
/oauth/gitlab/rid:your_unique_id/accessToken.html
URL format ensures an attacker cannot hand-craft an address acknowledged by TeamCity.If you do not already have a GitLab OAuth Application, follow the GitLab instructions to create an OAuth Application in one of the following scopes:
When filling out the Add new application form in GitLab:
Choose a Name for the application
Copy the Redirect URL from the TeamCity dialog into the GitLab form
Under Scopes, check api
Click Save application
Copy the Application ID and Secret from the GitLab Application settings and paste them into the TeamCity dialog.
For a GitLab CE/EE connection, you must also enter the base URL of the GitLab CE/EE server (for example,
https://gitlab.mydomain.com
) into the Server URL field. Note that this field is not needed in the case of a GitLab.com connection, because the base URL is alwayshttps://gitlab.com
.Click Save to save your new connection.
A GitLab icon will become active in several places where a repository URL can be specified. Click it to authorize TeamCity in your GitLab profile. TeamCity will be granted access to your repositories. If you configure multiple GitLab connections, the server URL will be displayed next to each icon, so it is easier to distinguish the server in use.
This type of connection supports Google Services. It uses the OAuth 2.0 protocol.
This connection is used for authentication in TeamCity with a Google account.
Before configuring a Google connection, you need to create a new Google project and register your app if you have not done it before.
To configure a Google connection in TeamCity:
In the Administration area, select Root project | Connections, and click Add Connection.
Select Google as the connection type.
TeamCity will display the redirect URLs required for registering an OAuth client. Copy them.
Go to the Credentials page in the Google project and create the OAuth client ID with the Web application type.
Paste your Callback URLs to the Authorized redirect URIs section in Google OAuth client ID. When the OAuth client is created, copy the Client ID and Client Secret.
Go back to the connection form in TeamCity, and enter the Client ID and Client secret.
Save the connection.
Now you can enable the Google authentication module.
Docker Registry
A connection to Docker Registry can be used to:
Sign in to an authenticated Docker registry before running a build / sign out after the build.
Clean up published images after the build.
See more information in the dedicated article.
Amazon Web Services (AWS)
The Amazon Web Services (AWS) connection allows defining AWS credentials once and using them in builds via the AWS Credentials build feature. You can use different AWS credential types: access keys, IAM Role, and the Default credential provider chain.
To configure an AWS connection in TeamCity:
In Project Administration | Connections, click Add Connection.
Select Amazon Web Services (AWS) as the connection type.
Provide a name to distinguish this connection from others.
The Connection ID field is filled out automatically. You can modify it and provide your own unique ID.
Select the AWS region where the target resources are located.
From the Type drop-down, select one of the credential types:
- Access keys
If you selected access keys as the credentials type, get the keys from the AWS console's Identity and Access Management section and provide them to TeamCity. See how to get these keys here .In the Access keys section in the TeamCity UI, do the following:
Specify permanent Access keys:
Access key ID. Enter the access key ID.
Secret access Key. Enter the secret access key.
It is recommended to change access keys regularly for security reasons. You will be able to do this after the connection is created via the Rotate key button.
TeamCity will not revoke old keys immediately. After a new key is generated, TeamCity will preserve the old inactive key for 24 hours and then remove it. The lifetime of old keys can be changed via the following properties:
teamcity.internal.cloud.aws.keyRotation.old.key.preserve.time.min
orteamcity.internal.cloud.aws.keyRotation.old.key.preserve.time.days
.To be able to successfully rotate access keys, TeamCity requires the
iam:GetUser
,iam:CreateAccessKey
, andiam:DeleteAccessKey
permissions.Configure temporary Session Settings:
Use session credentials. Check the box to use an endpoint that provides temporary access keys via AWS STS. Such credentials are short-term (the default session duration is 60 minutes). You can override the default session duration in the AWS Credentials build feature. These credentials do not belong to a specific user and can be provided on demand to grant temporary access to specific resources. We recommend using temporary credentials since they provide better security.
STS endpoint.
TeamCity generates this field automatically when changing the AWS region. The regional endpoint is recommended because it is faster and has lower latency. In addition, all calls to the regional endpoint are logged in AWS Cloud Trail as any regional service call.
Use the global endpoint if the selected regional endpoint is disabled on the Amazon account and you do not want to enable it.
Contact the TeamCity support team if you need to specify a custom endpoint for Amazon alternatives like MinIO.
- IAM Role
Using IAM roles, you can delegate access to your AWS resources to users, applications, or services that usually don't have these permissions. These entities will assume this role to get such access.You can use the IAM Role as the credentials type only if you already have at least one AWS connection with access keys or default credential provider chain configured in this TeamCity project.
Specify IAM Role:
AWS Connection. Select the AWS connection that will grant the specified IAM Role. Note that if the target AWS connection belongs to a parent TeamCity project, this connection's Available for sub-projects setting must be enabled.
Role ARN. Specify the ARN of the role to assume by the connection you are creating.
Configure Session settings:
Session tag. The session tag is required by Amazon. It is useful to locate sessions created by the TeamCity connection in AWS logs. TeamCity generates the tag automatically, but you can specify your own value.
STS endpoint.
TeamCity generates this field automatically when changing the AWS region. The regional endpoint is recommended because it is faster and has lower latency. In addition, all calls to the regional endpoint are logged in AWS Cloud Trail as any regional service call.
Use the global endpoint if the selected regional endpoint is disabled on the Amazon account and you do not want to enable it.
Contact the TeamCity support team if you need to specify a custom endpoint for Amazon alternatives like MinIO.
After the connection is created, you can view and copy the automatically generated external connection ID. We strongly recommend that you always add it to the trust policy in AWS to prevent the confused deputy problem. This ensures that only authorized TeamCity AWS connections will be able to use the specified IAM Role.
- Default credential provider chain
Select this type to provide access credentials according to the default chain. This approach provides an alternatives to storing credentials in plain text.
When this credentials type is used, TeamCity searches for credentials in the following order: 1. Java System Properties: aws.accessKeyId
and aws.secretAccessKey
. 2. Environment Variables: AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
. 3. Web Identity Token credentials from system properties or environment variables. ``` # In ~/.aws/config
Tick the Available for sub-projects option if you want this connection to be available for all subprojects of the current project.
Tick the Available for build steps option to allow choosing this connection in the AWS Credentials build feature feature settings.
Test and save the connection.
A configured AWS connection can supply credentials to the AWS Credentials build feature, artifact S3 storages, and other AWS connections that use IAM Roles.
Recommended Setup
Amazon key management guidelines recommend using IAM Roles instead of access keys and static IAM user credentials. Since IAM Roles issue short-lived credentials, this approach minimizes potential damage should your credentials get exposed (accidentally or as a result of a security breach).
TeamCity allows your project to access required AWS resources using connections that assume IAM Roles and do not rely on locally stored credentials.
In AWS Management Console, go to the IAM dashboard and navigate to the Roles tab.
Create a new IAM Role without any permissions. We will reference this role as "Role A".
Configure your TeamCity server machine to access AWS using this role instead of locally stored credentials. Required steps may vary depending on the exact type of your machine.
Other configurations: Web Identity, SAML
In TeamCity, create a new AWS connection of the Default Credentials Provider Chain type. Press Test Connection to ensure TeamCity uses your empty "Role A".
If you want subprojects to have access to this new connection, check the Available for sub-projects option. Otherwise, only the same project that owns this connection will be able to use it.
Create a second IAM Role ("Role B") with permissions required to access AWS resources (for example, EC2 instances or S3 buckets).
Modify the Trust relationships of this new Role B to allow Role A to assume it.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "your-Role-A-ARN" }, "Action": "sts:AssumeRole" } ] }In a TeamCity project that needs access to AWS resources, create another AWS connection.
Type — "IAM Role".
AWS Connection — the connection created in step 4.
Role ARN — the ARN of "Role B".
Note that if you configure this new connection in a subproject of a project that owns the primary "Default Credentials Provider Chain" connection, this primary connection must have its Available for sub-projects setting enabled (see step 5).
Click Test connection to ensure TeamCity can assume Role B.
Running STS get-caller-identity... Caller Identity: Account ID: <your account ID> User ID: <user ID:session> ARN: <Role B ARN>Save your new connection and reopen it. You should now see the External ID value of the connection.
Go back to the Trust relationships of Role B and add the extra condition:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "your-Role-A-ARN" }, "Condition": { "StringEquals": { "sts:ExternalId": "External-ID-copied-from-TeamCity" } }, "Action": "sts:AssumeRole" } ] }
As a result, you now have a following setup:
The primary Default credentials provider chain connection does not require locally stored credentials.
This shared primary connection has no permissions to access anything. To access AWS resources, it needs to assume other IAM roles.
Because of a condition configured in step 11, roles with actual access permissions can be assumed only by configured "IAM Role" TeamCity connections. TeamCity administrators cannot create more connections that utilize these roles.
To create more connections that can access Amazon resources, your AWS administrator must add additional conditions to whitelist external IDs of these new connections.
Amazon ECR
An Amazon ECR (Elastic Container Registry) connection allows accessing private and public AWS registries. With its help, the Docker Support build feature can store Docker/LXC images produced by a build to AWS.
Connection settings:
Setting | Description |
---|---|
Repository type | |
AWS region | (Only for private registries) Select an AWS region where the target resources are located. |
Credentials type |
|
IAM role ARN (only for Temporary credentials) | Specify a role to be used for generating temporary credentials. You need to create this role in advance in your AWS console and assign it to all the permissions you need. |
External ID (only for Temporary credentials) | Specify an external ID. We strongly recommend that you always define it when using temporary credentials. This ensures that only TeamCity will be able to use the specified IAM role. |
Default credential provider chain | Enable this option to automatically find access credentials according to the default chain. This approach is recommended if you do not want to store the credentials anywhere in the TeamCity environment. By default, it will use the values of |
Access key ID | Specify the access key ID. See how to get it here. |
Secret access key | Specify the secret access key. See how to get it here. |
Registry ID | Enter your account ID number. |
Slack
This type of connection is used to send notifications via Slack.
Before configuring a Slack connection, you need to create a Slack app with the following bot token scopes: channels:read
, chat:write
, im:read
, im:write
, users:read
, team:read
, groups:read
. You can add these in Features | OAuth & Permissions | Scopes of your Slack app.
To ensure your TeamCity server can connect to Slack, specify all the possible endpoint addresses of the server as Redirect URLs in Features | OAuth \& Permissions. In most cases, it would be enough to specify the Server URL set in Global Settings in TeamCity. However, if you use a proxy for your TeamCity server but access this server directly, the authentication in Slack might not work unless the server's IP address is also specified in Redirect URLs.
Now you can return to TeamCity, add a new Slack connection, and enter the following connection parameters:
Client ID and secret from the app's Basic Information page
A bot user token of your app
Configured Slack connections are used by Notifier build features and Service Messages.
JetBrains Space
This type of connection can be used for:
Publishing build statuses in JetBrains Space with the help of Commit Status Publisher.
Authenticating in TeamCity with a JetBrains Space account.
Creating projects, build configurations, and VCS roots from a JetBrains Space repository.
Starting builds on merge requests created in a JetBrains Space repository.
There are two ways to configure Space connections:
Automatically — TeamCity configures read-only Space applications with all required permissions and installs them to your Space instance.
Manually — requires you to manually create and install Space applications, then set up connection settings in TeamCity.
Automatic Connections
To configure a TeamCity project that builds and deploys a repository stored in JetBrains Space, you need two separate connections:
Organization connection — an entry point that stores common connection settings, which allow TeamCity to access your Space instance.
Project connection — allows TeamCity to access one specific project and its repositories.
You only need a single organization connection configured in a parent TeamCity project. However, to access separate Space projects, you will require separate project connections.
To configure an organization connection:
Navigate to Administration | <Your Project> | Connections.
Click Add Connection and choose JetBrains Space from the drop-down menu.
Choose Automatic: Organization Connection under Creation mode.
Enter the name for your new connection and click Create Space Application.
TeamCity will open a separate browser window that allows you to choose the required Space instance:
Space Cloud — click Install next to the required Space Cloud instance, or click Try another email if you are currently logged in using a different user account.
Space On-Premises — enter Space organization URL and click Install.
Enter the Space application's name and optional description, and click Install.
Click Approve all and go back to TeamCity to grant the newly installed Space application required permissions.
With the organization connection configured and installed, TeamCity has permissions to install other applications and scan for the list of projects. Add a new build configuration or create a new VCS root choosing organization connection as a source to view this list (you will need to authorize TeamCity at the first attempt):
Note that all projects initially have grayed-out Space icons. This means TeamCity cannot access repositories in these projects yet. To grant TeamCity required permissions:
Click a required project.
Click Proceed. TeamCity will create and install a new pre-configured application with all permissions required to access this specific project.
Follow instructions on the screen to navigate to Space administration dashboard and approve these permission requests.
You should now see all repositories added to this project. Space projects with installed applications that grant TeamCity access to their repositories show colored Space icons.
You can add more project connections to allow TeamCity to access additional Space projects within the same organization. To do this, navigate to Administration | <Your Project> | Connections and create new Space connections with the Automatic: Project Connection creation type. This option becomes available once you add an organization connection to this project (or its parent).
Individual Space project connections can also be employed by Commit Status Publisher and Pull Requests build features to interact with project repositories. Space organization connections in turn allow your users to log in TeamCity using their Space credentials.
Space applications configured by project-level automatic connections issue access tokens that VCS roots and build features utilize to access project repositories. These access tokens are non-personal, which means if a user who initially set up TeamCity projects and issued tokens leaves your organization, these projects remain functional and do not require an update. In case you need to reissue a Space token, click the Acquire New button under the "Authentication Settings" section of a VCS root.
Manual Connections
Configuring manual connections to JetBrains Space includes two steps: create a Space application with required permissions, and set up connection settings in TeamCity UI.
Create Space Application
Go to Administration | Applications and click New application.
Enter a convenient name and save the application.
Go to the app's Authorization tab and click Configure requirements under the In-context Authorization section. Enter the name of the Space project you are about to access from TeamCity.
Now, you need to set permissions that will be granted to the app in this project. Click Configure and enable the following permissions:
Required for authentication and Pull Requests:
Members | View member profile
Required for Commit Status Publisher:
Git Repositories | Report external check status
Code Review Comments | Post comments to code reviews
Required for Pull Requests:
Code Review | View code reviews
You can approve project-level permissions right in this Authorization tab if you are the project's administrator. Global permissions like viewing a member profile require a server administrator's approval.
Go back to the app's Overview and open the Authentication tab.
Enable Client Credentials Flow.
To be able to use authentication via Space in TeamCity or/and to create projects/configurations from Space repositories, enable Authorization Code Flow as well. Enter your TeamCity server's URL as the redirect URI. If you wish TeamCity to add a unique ID to your callback URL, start with creating a TeamCity connection and copy the URL from the Add Connection dialog. This URL will look like the following:
.../oauth/space/rid:your-unique-id/accessToken.html
. To ensure that your TeamCity server can always connect to JetBrains Space, specify all the other possible endpoint addresses of the server. In most cases, it would be enough to specify the Server URL set in Global Settings in TeamCity. However, if you use a proxy for your TeamCity server but access this server directly, the authentication might not work unless the server's IP address is also specified here.Copy the app's Client ID and Client secret.
Note: When you create a project in JetBrains Space, it does not automatically add you to this project as a member — this needs to be done manually. TeamCity will be able to see only those projects where you are listed as a member.
Configure Connection in TeamCity UI
When your Space connection is configured and installed, return to TeamCity and add a new JetBrains Space connection. In connection settings, enter the following connection parameters:
URL of the Space server
Client ID and secret of your Space application
Save the connection and proceed with adding a Commit Status Publisher or Pull Requests feature, enabling Space authentication, or creating a project/build configuration/VCS root.
NPM Registry
This type of connection allows the Node.js runner to access a private npm registry during a build. Since a project can have multiple NPM registry connections, you also need to configure the related build feature to choose a connection that Node.js build steps should utilize.
Connection settings:
Setting | Description |
---|---|
Scope | Specify an npm user/organization's scope (with or without the Leave empty if you want to use only one registry in this project. It will be used by |
Registry URL | Specify the npm registry URL in the following format: |
Access token | Specify a token if it's needed for accessing the registry. Leave empty for anonymous access. Note that token-based authentication could differ depending on the registry type. See instructions for npm Enterprise, Space Packages, or GitHub Packages. |
Save the connection and proceed with adding an NPM Registry Connection build feature.
Perforce Administrator Access
This type of connection allows processing task streams on your Perforce server. In the connection settings, enter the host and user credentials for accessing the Perforce server (the user must have the admin permission).