Code Review Action

Inputs and outputs of the tesslio/code-review-action GitHub Action, which runs Tessl Code Review on a pull request in CI.

Tessl Code Review is in beta. Behavior and output formats may change in upcoming releases.

The tesslio/code-review-action GitHub Action runs Tessl Code Review on a pull request and publishes one native GitHub review. This page is the input and output reference. For how to add the Action to a repository, choose a cadence, and enable a gate, see Set up Tessl Code Review.

The Action owns pull request resolution, checkout of the exact head, Tessl CLI setup, its own check run, and result artifacts. The Tessl CLI the Action installs runs the review and publishes it. The caller workflow owns when reviews run, the permissions the job holds, the token secrets, and whether findings block merging.

Advisory versus gate

One input decides the consequence of a review, and it appears throughout this reference: mode. In advisory mode the review is published as a GitHub COMMENT and no review outcome fails the Tessl Code Review check. In gate mode the review publishes the verdict it reached (approving when nothing requires changes, requesting changes otherwise) and the check follows it, so branch protection can hold the pull request on a blocking finding. A technical failure to run or publish fails the job in both modes. See Enable gate mode for the full chain from finding to merge block.

Inputs

Input	Required	Default	Purpose
tessl-token	yes	none	Tessl API token the CLI uses. Pass it from a repository secret; never inline it.
mode	no	advisory	Publication policy: advisory or gate. See Advisory versus gate.
profile	no	standard	Named review profile, or a repository-relative path to a .yml/.yaml profile. See Configuration files.
lenses	no	''	JSON array with the complete ordered lens selection. Replaces the profile's default lenses rather than adding to them. At most eight lenses.
effort	no	''	Reasoning effort for every lens: low, medium, high, or adaptive. Overrides any profile effort. Empty lets the profile and CLI resolve it.
cli-version	no	latest	Tessl CLI version to install. latest tracks the current release. Pin an exact version to fix review behavior alongside the Action reference.
github-token	no	${{ github.token }}	The identity that authors the published review. See github-token.
allowed-associations	no	''	Comma-separated author associations whose comments may request a review, for example OWNER,MEMBER,COLLABORATOR. Empty accepts any commenter. Applies to comment events only, and never refuses the pull request's own author.
approver-logins	no	''	Comment-author logins, separated by commas or newlines, permitted to ask the review to approve instead of reviewing. See approver-logins.
pr-number	no	''	Pull-request number for events that carry no pull-request context, such as a comment or a manual dispatch. Empty on pull_request events, where the Action resolves the pull request itself.

github-token

Left at its default, the review is authored by the workflow's own token, which posts as github-actions[bot], the same identity as the repository's other jobs. Pass a token that carries its own identity to author the review distinctly:

• a GitHub App installation token minted per run with actions/create-github-app-token, so reviews arrive as the App's [bot] login; or
• a dedicated machine user's personal access token.

A supplied token needs pull-requests: write to publish. contents: write is optional and buys exactly one thing: reopening a resolved thread whose finding still requires changes. GitHub files thread resolve and unresolve under Contents, so without write there the reviewer republishes the finding as a new comment. Whether an App's approving review satisfies a required-approving-review rule is decided by the App installation's write access, not by the token's scopes. See Choose the reviewing identity for the worked workflow.

approver-logins

A comment can instruct Tessl to approve a pull request rather than review it, which skips the review. The same allowlist also permits requesting a full re-review of the whole change instead of the narrower incremental round, so a login named here gains both privileged intents. Repository owners, members, and collaborators may already do both, by the association allowed-associations reads. A GitHub App cannot: it comments with association NONE whatever its permissions, so no association names one. List a login here, carrying the [bot] suffix the event payload spells (capitalization does not matter), to permit that specific commenter. Naming a login here also admits it past allowed-associations for an ordinary review, so read the two inputs together. Empty names no one and does not stop a member using either.

Outputs

A later step in the same job can read these once the Action step has an id. Give the uses: step id: review, then reference steps.review.outputs.<name>.

Output	Meaning
status	Terminal Action status.
head-sha	Exact reviewed pull-request head SHA.
review-id	Created or reused GitHub review ID, when available.
result-path	Absolute path to the structured CLI result on the runner.
result-artifact	Name of the retained public result artifact on the workflow run.

Use the outputs for reporting and workflow coordination. Do not add a second review publisher: publication, retry reconciliation, and duplicate prevention belong to the Tessl CLI the Action runs, and a second publisher gives the repository two paths that can disagree.