How the pull request review works
GitHub App sync creates the project from the repository. The GitHub Action then runs with mode: review. It posts one pull request comment and uploads workflow artifacts. The documented GitHub Action posts one review comment on the pull request and uploads downloadable workflow artifacts (a JSON result, a Markdown summary and, when enabled, a PDF report). Config-driven gates in .cloudeval/config.yaml decide what happens next: enforcement: comment_only publishes the review without blocking the merge, and enforcement: block_pull_request fails the job when a gate isn't met. Repository permissions still apply.
Minimal workflow
Copy the minimal workflow from the GitHub Actions docs. Set mode: review and upload_artifacts: true. Do not set github_checks. Authenticate with CLOUDEVAL_ACCESS_KEY. The job reviews the configured Azure ARM or Bicep-compiled ARM project, or a static AWS CloudFormation template when that beta input is the source. A green job is not itself the review; open the comment and the uploaded artifacts.
Gates
ci.gates in .cloudeval/config.yaml chooses the outcome. enforcement: comment_only publishes the review without blocking the merge. enforcement: block_pull_request fails the job when a gate is not met. Repository permissions still apply. Use comment_only while you are calibrating thresholds, then switch a gate to block_pull_request only for the checks the team agrees should stop a merge.
What reviewers get
Reviewers get one pull request comment with the gate result and posture, plus workflow artifacts: review.json, review.md, and an optional review.pdf when that upload is enabled. Diagram PNG, JPEG or SVG exports stay a CLI workflow. PR diagram diffs are not part of the current documented workflow. Keep the source revision with the comment so the finding can be traced to the change.
Current boundaries
The documented GitHub Action posts one review comment on the pull request and uploads downloadable workflow artifacts (a JSON result, a Markdown summary and, when enabled, a PDF report). Config-driven gates in .cloudeval/config.yaml decide what happens next: enforcement: comment_only publishes the review without blocking the merge, and enforcement: block_pull_request fails the job when a gate isn't met. Repository permissions still apply. Coverage is Azure, plus AWS CloudFormation (beta). Inputs are ARM JSON, Bicep compiled to ARM, and live Azure sync. There is no Terraform support, no live AWS connection, and no hosted MCP endpoint.
Best use case
Use this path when your team wants a repeatable gate for Azure infrastructure review before merge instead of a one-off dashboard check after deployment. Pair it with the cost and security review when the same pull request needs both signals, and with the architecture diagram answer when reviewers also need a picture of the change.
