Skip to main content
A release report answers one question: is this set of changes safe to ship? You pick a release in a connected repository, CloudThinker reads the actual diff against the previous release, and you get the risks, the steps to take, and a place to record Approve or Hold.

​
Prerequisites

  • A repository connected through Review setup on GitHub, GitLab, Bitbucket, Azure DevOps or AWS CodeCommit.
  • The right workspace role for what you want to do. See roles.

​
Analyze a release

1

Open Analyze release

Go to Review → Releases and click Analyze release.
2

Pick the repository and release

Choose the Repository. A release is a Git tag. CloudThinker lists the tags newest first and preselects Not released yet when the default branch has changes since the last release. The analyze button calls the same thing unreleased changes. Use the search box to find a branch or tag, or paste a commit ID.AWS CodeCommit has no tag support, so on CodeCommit the picker offers branches only.
3

Check what it compares with

CloudThinker picks the base for you: the previous release on the same line. A release line is a chain of tags that build on each other in Git history. Tags on your default branch form one line, and a tag on a branch that forked off it, such as a hotfix branch, starts its own. To compare with something else, click Change next to the base and pick another release, branch or commit.
4

Start the analysis

Click Analyze (the button names the release, for example Analyze unreleased changes). It takes about 5 minutes, and you can leave the page. No notification is sent when it’s ready, so check the Needs decision tab.Success state: the release shows Analyzing, then lands in the Needs decision tab once the report is ready.
If a release already has a report, the dialog offers Open report and Analyze again instead. Analyzing again creates a new report; the older one is marked Replaced and stays readable, but only the newest one takes a decision.
By default, an analysis only starts when someone clicks Analyze release. To start a report for every pushed tag, turn on Analyze new release tags in the Review section of Review → Settings. The setting shows only when release reports are turned on for your workspace. If you don’t see it, contact support. Each report is one agent run, so leave it off if you tag often.

​
Read the report

The top card gives the verdict: A PR or MR counts as at risk when any of these is true:
  • A blocking risk cites it.
  • It has a high or critical finding open.
  • Review never reviewed it.
For example, a release of three PRs with Impact 50, 30 and 20, where only the 30 one has a high finding open, shows 30% at risk. Below it, tiles show Commits, Lines, Reviewed by CloudThinker and Pipeline on head. Pipeline on head is the CI status of the release’s head commit and links to that run in Pipelines. It reads No pipeline seen when Review has no run for that commit. Then come three sections that never repeat each other: A risk is Blocking when someone should fix it, or explicitly accept it, before shipping. It’s Watch when the rollout needs attention but the evidence doesn’t justify a hold. CloudThinker checks nine risk areas on every release and lists only the ones that matter for it: The report also lists the release’s PRs or MRs with their review status, and a Quality map that highlights changes with low quality, no review, or a blocking risk. If CloudThinker couldn’t read part of the range, an Assessment limits note says so rather than guessing.
Counts are a snapshot. If you fix an open finding after the report, the report still shows it. Analyze the release again for current numbers.

​
Work through the steps

Each open step has Mark resolved and Dismiss. Dismissing asks for a reason, and Re-open undoes either. When you analyze the same release again, steps you already settled are Carried over if the instruction hasn’t changed, so you don’t redo work. Marking a step resolved is your claim; only a new analysis confirms the risk is gone. To get help with the open steps, click Fix with CloudThinker: Click Download PDF to share the report outside CloudThinker.

​
Approve or hold

1

Make the call

On the report, click Approve or Hold. When a blocking risk is still open, the button reads Approve anyway.
2

Add a note

The note is optional, with two exceptions. Approving with a blocking risk open asks Why is it safe to ship? Holding a release with no blocking risk asks Why are you holding it?Success state: the report shows “Approved by” or “Held by” with your name and note, and the release moves to the Approved or On hold tab.
A decision is a record in CloudThinker. It doesn’t merge, tag or deploy, and nothing is sent to your Git provider, so it never blocks your pipeline. To change it later, click Change decision. Replaced reports keep the decision they had.
The report keeps only the latest decision and note. Change decision overwrites the earlier one, and there’s no decision history. If you need an audit record, click Download PDF right after you decide: the PDF includes the decision and its note.
The Releases list works as a decision queue:

​
Troubleshooting

There’s no tag to analyze and the default branch has nothing new since the last release. Push a tag, or pick a branch or commit with the search box.
The base you chose doesn’t exist or isn’t an ancestor of the release. Click Change and pick another base.
The analysis stopped before it finished, and no score was published. Start a new analysis from Analyze release.
AWS CodeCommit can’t link commits to PRs, so the report marks those counts as not available. The risk analysis still reads the full diff.
The report is CloudThinker’s judgment on the diff, so details can shift between runs. Treat the status and the blocking risks as the signal, not small changes in numbers.

​
Next steps

Pipelines

Get a root cause for every failed CI run

Review Insights

Track review quality across repositories over time

Learnings

Stop the same risks from coming back in future reviews

Review overview

See everything Review does across your repositories