The first sync
When a repository is connected, Pealboard reads what is already in it. Nothing is created, nothing is renamed, and nothing in GitHub changes.
What is read
Section titled “What is read”- Issues, open and closed, with their bodies.
- Comments on those issues.
- Labels and milestones.
- The organization’s projects, their fields, and the items in them.
Pull requests are not read as work items. An issue’s linked pull requests are shown on the issue when GitHub reports them.
How long it takes
Section titled “How long it takes”Issues appear in batches as they are read, oldest repository first. A repository with a few hundred issues is usually complete in under a minute; tens of thousands take longer, and the Issues screen fills in while it runs.
Two things slow it down and both are GitHub’s, not Pealboard’s: an installation’s hourly request budget, and GitHub’s separate budget for project data. If either runs low, Pealboard pauses the backfill and resumes when the budget refreshes. Writes you make continue during a pause.
How it stays current afterwards
Section titled “How it stays current afterwards”| Source | When |
|---|---|
| GitHub webhooks | The moment something changes in GitHub. This is the normal path. |
| Reconciliation | Every hour, for every repository, to repair anything a dropped webhook missed. |
| Opening an issue | Re-read from GitHub if Pealboard’s copy is more than 60 seconds old. |
| Sync now | On demand, in Settings → GitHub. |
Every object carries the time it was last read: “Synced 12 seconds ago” appears on an issue and in Settings → GitHub for a repository. If a sync failed, the line says what failed and when the next attempt is, rather than showing a spinner.
If something is missing
Section titled “If something is missing”Read Troubleshooting, which covers sync delays and the case where a repository does not appear at all.