For the complete documentation index, see llms.txt. This page is also available as Markdown.

Azure DevOps

For using repositories from Azure Devops with Terrakube workspaces and modules you will need to follow these steps:

Manage VCS Providers permission is required to perform this action, please check Team Management for more info.

Navigate to the desired organization and click the Settings button, then on the left menu select VCS Providers

If you prefer, you can add a new VCS Provider directly from the Create workspace or Create Module screen.

Click the Azure Devops button

In the next screen click the link to register a new OAuth Application in Azure Devops

In the Azure Devops page, complete the required fields and click Create application

Field
Description

Company Name

Your company name.

Application name

The name of your application or you can use the Organization name

Application website

Your application or website url

Callback URL

Copy the Callback URL from the Terrakube URL

Authorized scopes (checkboxes)

Only the following should be checked: Code (read) Code (status)

You can complete the fields using the information suggested by terrakube in the VCS provider screen

In the next screen, copy the App ID and Client Secret

Go back to Terrakube to enter the information you copied from the previous step. Then, click the Connect and Continue button.

You will see an Azure Devops window, click the Accept button to complete the connection

Finally, if the connection was established successfully, you will be redirected to the VCS provider’s page in your organization. You should see the connection status with the date and the user that created the connection.

And now, you will be able to use the connection in your workspaces and modules:

Webhooks

Azure DevOps (dev.azure.com and Azure DevOps Server) supports triggering workspace runs from repository activity, using either connection type (OAuth/Personal Access Token, or Service Principal/Managed Identity). There are two ways to detect changes:

Inbound service hooks (default). When a workspace with an Azure DevOps VCS is saved, Terrakube creates an Azure DevOps service hook subscription that posts to the Terrakube webhook endpoint. Each delivery is authenticated with a per-webhook token, and commit status is reported back to Azure DevOps as the run progresses. Supported events:

Terrakube event

Azure DevOps eventType

Push

git.push

Pull Request

git.pullrequest.created, git.pullrequest.updated

Pull Request comment

ms.vss-code.git-pullrequest-comment-event

Because service hooks are delivered from the Azure DevOps cloud, the Terrakube webhook endpoint must be reachable from the public internet, and the connection needs Edit Subscriptions permission to create them.

Outbound commit polling (opt-in). If Terrakube runs on a private network that the Azure DevOps cloud can't reach, inbound service hooks will silently fail. Polling reverses the direction: Terrakube periodically makes an outbound call to fetch the tip commit of each Azure DevOps workspace branch and starts a run when it changes, reusing the same credentials already used for cloning — no inbound network exposure required. Polling is disabled by default; enable it with these API environment variables:

Environment variable
Default
Description

AzureDevOpsPollingEnabled

false

Enable outbound commit polling.

AzureDevOpsPollingInterval

15000

Milliseconds between polls of each workspace branch.

AzureDevOpsPollingInitialDelay

10000

Milliseconds to wait after startup before the first poll.

The first observed commit for a branch only records a baseline and does not trigger a run. Branch and file-path filters on the workspace webhook are applied the same way as for inbound pushes.

Last updated

Was this helpful?