Skip to main content
This page covers the Connect and Events steps of the Review setup wizard: which credentials each Git provider takes, the minimum scopes, and the webhook that tells CloudThinker a pull request (PR) or merge request (MR) changed. Start the wizard from Review setup, then come here for your provider.

​
Prerequisites

  • Workspace Admin in CloudThinker, with the Review Setup dialog open at the Connect step.
  • On the provider side, permission to install apps, create access tokens, or create IAM roles for the repositories you want reviewed.
  • Azure DevOps: permission to create service hooks in the project (Project Administrator by default).

​
Pick an auth method

Self-hosted GitLab is the only self-hosted provider you can connect in the wizard. GitHub connects to github.com and Bitbucket to bitbucket.org, so GitHub Enterprise Server and Bitbucket Data Center aren’t options there.
Prefer a project, group, workspace or repository token over a personal one where your provider offers it. Comments then come from a bot user, access stays scoped to those repositories, and you can revoke it without touching anyone’s account.

​
GitHub

1

Install the GitHub App

Click Install GitHub App. GitHub asks you to pick an organization or account, then All repositories or Only select repositories. Review can only list the repositories you grant here. GitHub shows the app’s full permission list on that screen before you approve. It includes Pull requests: Read and write for comments and Contents: Read and write, which Apply fix, autofix and conflict resolution need to push commits.
2

Return to the wizard

After you approve, GitHub sends you back and the wizard continues on its own. Webhooks come with the app, so there’s no Events step.Success state: the dialog shows Connected and moves to Repositories.
To grant a repository later, open your organization or account settings on GitHub, go to GitHub Apps, click Configure next to the CloudThinker app, and add it under Repository access. Then add it in Review with Add repository.
Installing an app on a GitHub organization needs an organization owner. If you aren’t one, ask an owner to approve the install.

​
GitLab

OAuth connects to GitLab.com only. For self-hosted GitLab, use an access token. With OAuth, comments appear as the person who connected.
  1. Open the OAuth tab and click Connect to GitLab.
  2. Approve access in GitLab. CloudThinker asks for these scopes: api, read_api, read_repository, write_repository, openid, email and profile.
  3. Back in the wizard, add the webhook.

​
Bitbucket

  1. Open the OAuth tab and enter your Bitbucket workspace name (the <workspace> in bitbucket.org/<workspace>/repo).
  2. Click Connect to Bitbucket and approve access.
With OAuth, comments appear as the person who connected. Webhooks register automatically.

​
Azure DevOps

1

Create a personal access token

In Azure DevOps, go to User settings → Personal access tokens and click New Token. Pick the organization, set an expiration date, and enable these scopes:Copy the token. Azure DevOps posts comments as the person who owns the PAT, so create it from a dedicated service account. Then reviews keep working when someone leaves. Give that account the Basic access level (Stakeholder can’t use Repos) and Contributor on the project, so it can read code and comment on pull requests.
2

Connect in the wizard

Fill in Organization URL (for example https://dev.azure.com/myorg), Project and Personal Access Token. Click Validate PAT, wait for Token works, then click Connect.The connection covers the repositories in that one project. To review repositories in another project, set up Review in a separate workspace for it.Success state: the dialog shows Connected and moves to Events.
3

Add the service hooks

Follow Configure webhooks.

​
AWS CodeCommit

Both methods use a script the wizard generates for you. Run it in AWS CloudShell, or in any bash shell with the AWS CLI and credentials for the account (the access keys script also needs jq). A connection covers one AWS account and one region: the region you pick in the wizard.
  1. Select IAM Role (recommended) and choose the AWS Region. The wizard creates an External ID for your workspace.
  2. Copy the script and run it in AWS CloudShell. It creates a role named CloudThinkerCodeCommitAccessRole with a trust policy scoped to CloudThinker and your External ID. If that role already exists, for example from an earlier setup, the script reuses it: it refreshes the trust policy for the new External ID and prints the existing ARN.
  3. Copy the role ARN from the script’s output into Role ARN, then click Connect.
The script attaches one inline policy with these actions:It doesn’t grant codecommit:GitPush or codecommit:CreatePullRequest. Auto-resolve conflicts needs both, so add them if you turn it on:
  1. In the IAM console, open Roles → CloudThinkerCodeCommitAccessRole (or Users → CloudThinkerCodeCommitUser for access keys).
  2. On Permissions, edit the inline policy: CodeCommitReviewAccess on the role, CodeCommitReviewAccessKeyPolicy on the user.
  3. Add codecommit:GitPush and codecommit:CreatePullRequest to the CodeCommitReviewActions statement and save.
The IAM role’s trust policy lets only CloudThinker’s AWS account assume the role, and only with your workspace’s External ID. The script you copy from the wizard contains the full trust policy, with that account ID, so your security team can read it before you run it. The Access Keys method creates an IAM user named CloudThinkerCodeCommitUser with the same policy instead.
If the wizard says no repositories found yet, the connection works but the credentials can’t see any repositories. Check the IAM permissions and the region.

​
Configure webhooks

GitHub and Bitbucket need nothing here. For the other three, the Events step shows a webhook URL and Secret token to copy.
  1. In GitLab, open the group or project and go to Settings → Webhooks → Add new webhook. Group webhooks need GitLab Premium or Ultimate. On the Free tier, add the webhook to each project instead.
  2. Paste the URL and Secret token from the wizard. Leave Enable SSL verification on.
  3. Enable Merge request events and Comments. Add Pipeline events if you use pipeline analysis, Tag push events if you use releases, and Push events if you use auto-resolve conflicts. Without Push events, a push to a target branch never reaches CloudThinker, so conflicts it causes aren’t checked.
  4. Save the webhook, then click Mark as Configured in the wizard.
To check delivery, click Test → Merge request events next to the webhook, then edit it and look under Recent events.
Success state: you open a test PR or MR in a selected repository and a CloudThinker progress comment appears on it.

​
Token expiry

GitLab and Bitbucket access tokens and Azure DevOps PATs expire on the date you set. Reviews stop when they do, and the Review page shows Reconnect your Git provider. Note the date when you create the token, and replace it before then: open Review → Settings, and in the Connection section open the actions menu (⋯) and click Update token. CodeCommit access keys don’t expire on their own, but rotate them the same way. Review doesn’t warn you before a token’s expiry date, so put a reminder in your own calendar.

​
Disconnect a provider

Remove setup deletes every reviewed MR/PR on Review → Reviews and every pipeline record in the workspace. Setting Review up again doesn’t bring them back.
1

Remove the setup in CloudThinker

Open Review → Settings. In the Connection section, open the actions menu (⋯) and click Remove setup, then confirm. Review stops on every repository and the provider connection is removed. On GitHub, CloudThinker also uninstalls its app, and on Bitbucket it deletes the webhooks it registered. You can set it up again later.
2

Revoke access on the provider

Confirm the GitHub App is gone from your organization’s GitHub Apps settings, or revoke the OAuth grant, delete the access token or PAT, or delete the IAM role or user the script created.

​
Troubleshooting

Cause: usually a wrong URL or name, or a missing scope:
  • GitLab: the URL has a trailing path, or the token’s role is below Developer.
  • Bitbucket: the workspace name or repository slug is wrong, a permission is missing, or you chose a workspace or project token on a plan without them.
  • Azure DevOps: the Organization URL isn’t https://dev.azure.com/<org>, the Project name is wrong, or the PAT was made for another organization.
Fix: correct the field, confirm the scopes in the tables above, and create a new token if needed. The wizard keeps what you typed, so you only replace what was wrong.
Cause: the webhook is missing, has the wrong secret, or lacks a trigger.Check: open the webhook delivery history in your provider and look for failed requests.Fix: compare the URL, secret and triggers against Configure webhooks. For Azure DevOps, confirm all service hooks exist.
Cause: the Pull request commented on hook uses resource version 1.0.Fix: edit that service hook and set Resource version to 2.0.
Cause: you connected with OAuth, and Bitbucket no longer lets CloudThinker find your workspace on its own.Fix: click Set workspace, enter your workspace name in Bitbucket workspace, and click Save workspace.

​
Next steps

Finish Review setup

Select repositories, choose a review mode and get your first review.

Mention commands

Talk to the reviewer from a PR or MR comment.