> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt. # Running Code Review in your own GitHub CI For GitLab merge requests, call the Tessl CLI directly from your own pipeline. See [Run Code Review with GitLab](/tutorials/code-review-in-gitlab.md). :::warning The GitHub App is the supported way to run Tessl Code Review. This page is kept for people who cannot install a GitHub App. It is unsupported and not maintained, and it may fall behind the CLI. ::: The [`tesslio/code-review-action`](https://github.com/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. To set up reviews the supported way, see [Set up Tessl Code Review](/tutorials/setting-up-agentic-code-review.md). 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. In gate mode, `requestChangesAt` sets the consequence baseline, `reviewMode` sets the strength required to block, `mode` decides whether the check then fails, and branch protection decides whether a failing check holds the pull request. ## 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](#advisory-versus-gate). | | `profile` | no | `standard` | Named review profile, or a repository-relative path to a `.yml`/`.yaml` profile. See [Configuration files](/reference/configuration.md#tessl-code-review-yml). | | `lenses` | no | `''` | JSON array with the complete ordered lens selection. Replaces the profile's default lenses rather than adding to them. At most 12 lenses, unless your organization has a different limit. | | `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`](#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`](#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`](https://github.com/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. Mint the token in a step before the Action, for example with [`actions/create-github-app-token`](https://github.com/actions/create-github-app-token), and pass its output as `github-token`. ### `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.`. | 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.