Ryker / Docs / GitHub and pull requests

GitHub and pull requests

Ryker uses a GitHub App to read repositories, open draft pull requests, and take part in reviews. The App installation chooses which repositories it can access; Ryker’s environments choose where each one is used.

On this page

Create and install the App

In your GitHub account or organization, open Settings › Developer settings › GitHub Apps › New GitHub App. Use GitHub’s registration guide for the form, with the permissions and events below.

Generate a private key and install the App on the repositories Ryker should use. In Ryker, open Integrations › GitHub and enter the App ID and private key. Copy Ryker’s webhook URL and secret into the App’s settings and keep webhooks active.

Set repository permissions

PermissionAccessPurpose
ContentsRead/writeRead code and publish task branches.
IssuesRead/writeRead and reply to issues.
Pull requestsRead/writeCreate drafts, comment, and review.
ChecksReadRead check results.
Commit statusesReadRead commit status.
ActionsRead; write for rerun/cancelInspect and manage workflow runs.
MetadataReadRead repository details.

Import the repositories under Work › Repositories, then add them to environments. A repository can be read-only in Ryker even when the App has write access.

Subscribe to events

  • For conversations and reviews: Issue comment, Issues, Pull request, Pull request review, and Pull request review comment.
  • For CI: Check run, Check suite, Status, Workflow run, and Workflow job.
  • For repository changes: Repository.

Ryker retrieves App deliveries every 30 seconds, so GitHub does not need a direct connection to your host. For direct delivery, expose only /v1/github through HTTPS. See network access and GitHub’s event reference.

Publish a draft pull request

Enable draft publication under Integrations › GitHub before Ryker can open a pull request, whether automatically or with an operator’s approval. A confirmed task that includes the repository can publish its reviewed change automatically. Otherwise, a configured operator uses Create draft PR.

Before publication, the co:op worker compares the change with the current repository, rebases it, and runs the configured checks. Ryker records the reviewed commit and tree, then publishes that exact change on its own branch. A failed check, conflict, or policy finding blocks publication. Missing or unavailable checks can still produce an unverified draft, with the gaps listed on the pull request and task card.

The GitHub App’s private key stays with Ryker. For authorized publication, the trusted worker gets a short-lived repository token outside the model’s sandbox. It refuses to overwrite a branch someone changed outside Ryker.

Your team reviews the draft, marks it ready, and merges it. Ryker has no merge operation. For a complete example, follow your first code change.

Follow CI and review feedback

Comments on a Ryker-created pull request return to the original task. Failed CI on the published commit can resume that task, which fixes the problem within its scope and updates the same draft.

Ryker reports check results, merges, and closures in the task’s thread. It also checks open pull requests every ten minutes in case an event delivery was missed.

For 30 days after publication, a deployment or Terraform message in another watched channel can link back to the task when it names the exact pull request, branch, or commit. A shared topic or repository name is not enough to establish that connection.

Ask Ryker to review a pull request

Paste the pull request URL in Slack, GitHub, or browser Chat and say what you want examined. For requests made on GitHub, the person asking needs write or admin access to the repository.

Ryker can read the diff and discussion, leave inline comments, and submit a review requesting changes. Replies stay in the review thread, and each review records the commit it examined. Approving pull requests is a separate repository setting, off by default.

Check the connection

Ask about an imported repository from a conversation using its environment. Check that the answer cites actual files. Then use the code-change walkthrough to check publication.

If a repository is missing, check the App installation and the environment. If review or CI follow-ups are missing, check the subscribed events, webhook secret, and App deliveries, then inspect Activity and Failures.