GitHub connects either through the Coroid GitHub App or a personal access token. Configure it at Settings → Connections → Source control.
App or token
Prefer the App. It grants access per repository rather than per user, keeps working when the person who set it up leaves, and receives webhook events without polling.
Use a token where App installation needs an organization admin approval you cannot get.
| GitHub App | Personal access token | |
|---|---|---|
| Access scope | Per repository | Everything the user can see |
| Survives the installer leaving | Yes | No |
| Webhook events | Yes | Polling |
| Attribution | The App | The token owner |
Installing the App
Choose GitHub at Settings → Connections → Source control and follow the install flow. GitHub asks which repositories to grant; you can change that later from GitHub's own settings.
If a repository does not appear when creating a project, the App almost certainly was not granted that specific repository — that is the most common cause by a wide margin.
Using a token
Create a classic token with the repo scope, or a fine-grained token with read
and write on contents and pull requests, then paste it into the source control
settings.
Tokens are encrypted at rest, never returned by the API, and never included in settings exports.
GitHub Issues
The same connection supports importing issues as work. See Importing work.
Events that become work
With the App, an event automation can send a pull request, a new issue or a comment that mentions Coroid to Qualification. See Triggers and destinations.
Qualified work from these events starts on its own only when its author has write, maintain or admin access to the repository. Coroid asks GitHub for each event. For a pull request, the author is the person who opened it, not whoever labeled or merged it. Work from anyone else is created and waits for someone to start it. A comment that mentions Coroid counts only when its author has write access.
Reviewing pull requests
With the App, Coroid checks and reviews pull requests that people and other tools open, not only Coroid's own. Coroid Quality Control runs the project's checks and posts the Coroid Quality Control check. Coroid Review posts a review with comments on the lines it questions, and a check named Coroid Review. Both are set in Quality Control, under Pull requests. See Pull requests.
What Coroid does in your repository
- reads code to understand and change it
- creates a branch per task
- pushes that branch and opens a pull request against your base branch
It never commits to your default branch or merges on its own. A merge happens only when a person merges the pull request in GitHub or presses Approve & merge in Coroid.
A project set to Local only does the first of these and nothing else: Coroid reads and pulls, and keeps branches, reviews and checks inside Coroid. It does not push, open or comment on pull requests, or post check runs, even when the App or token would allow it. See Synced or local only.
Your branch protection, required checks and review rules apply unchanged. Approve & merge merges through the pull request too, so the same rules decide whether it succeeds. See Merging.
Security
Security uses the App to post the Coroid Security check and, with optional
permissions, to import GitHub's own security alerts and to check merge queues.
See GitHub permissions and the Coroid Security check.