Skip to content
Slipwaydocs

Checks and PR comments

Every run of a pipeline that came from a linked repository reports back to that repository. Nothing has to be configured in the pipeline file: the connection’s permissions decide what the provider shows.

Checks on the commit

Section titled “Checks on the commit”

Slipway writes one check per job and one roll-up per pipeline on the commit a run executed against:

Check Name Shows
Job slipway / <pipeline> / <job> The job’s state, its duration or failure reason, and a link to the job’s logs. A failed job lists the steps that failed, test report totals and the job’s annotations.
Run slipway / <pipeline> The run’s state (“failed: 1 of 3 jobs failed”, “passed in 42s”) and a table of every job with its result, duration and link.

Checks appear as soon as the run is queued, so a pull request shows every job that is coming, and are updated in place as jobs start and finish. Matrix jobs report under their expanded name (test (go 1.27)).

On GitHub App connections these are check runs, with annotations placed on the changed lines. On GitHub connections that use a personal access token, and on GitLab, Bitbucket, Azure Repos and Gitea, the same names and states are written as commit statuses (GitLab also reports the pipeline-level check to the merge request’s external status checks when the project uses them). Branch protection and merge rules can require either kind by name.

Jobs bound to an environment additionally record a deployment status for that environment on providers that support them (GitHub, GitLab), from waiting for approval through success or failure.

Pull request comments

Section titled “Pull request comments”

A run triggered by a pull request also keeps one comment per pipeline on the pull request:

### ci #128: failed: 1 of 3 jobs failed


Commit `a1b2c3d4e5f6` on feature/checks · [View run #128](https://ci.example.com/acme/api/runs/run_…)


| Job | Result | Duration |
|---|---|---|
| [build](…) | passed | 12s |
| [test](…) | failed | 30s |
| [deploy](…) | skipped | |

The comment is created when the run is queued and edited in place as jobs finish, so a pull request never fills up with one comment per push. A pipeline that runs again for a new commit of the same pull request updates the same comment.

How it is delivered

Section titled “How it is delivered”

Reporting is asynchronous: the control plane queues updates and a worker writes them to the provider, retrying transient failures and rate limits (Retry-After is honoured). An update that arrives late, after a newer state of the same check was already written, is skipped, so the provider always shows the latest state. Deleted repositories and revoked connections drop their updates silently.

Every write is attributed to the connection’s identity: the GitHub App, or the user whose token the connection uses.

Section titled “Related”