Azure DevOps
OAuth apps are deprecated in Azure DevOps.https://devblogs.microsoft.com/devops/no-new-azure-devops-oauth-apps as an alternative for now a managed identity can be used but the setup is only available using the API, for more information please check:
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
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.
The PR comment plan/apply workflow (Post Plan on PR / Allow Apply via PR Comment, terrakube plan / terrakube apply comments) is currently only available for GitHub, GitLab, and Bitbucket. Azure DevOps pull request events can trigger jobs, but results aren't posted back as PR comments yet.
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:
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?