GitHub source workflow
How Webpresso identifies, deploys, and records a repository revision. This is a platform capability of the engineering department, not a separate product.
Connect a project
1. Connect GitHub
An organization owner or admin starts the GitHub App flow from Source settings and chooses the installation that can read the intended repository.
2. Select the exact source
Choose a connected repository, ref, and source root. Webpresso resolves a full Git revision and proves that directory before creating or relinking a project.
3. Keep source in GitHub
Your team and your coding tools work through normal commits and pull requests. Webpresso does not host, mirror, or edit the repository.
4. Verify releases
Deployment records point to immutable repository revisions so health checks and release evidence remain attributable to the source that shipped.
Repository access
Identity sign-in and repository authorization are separate. Webpresso accepts a repository only when the current user can see it and the selected GitHub App installation can access it. Provider credentials remain inside the GitHub adapter and are not returned to the browser or stored with the project.
Current source record
- GitHub repository identity and canonical URL
- Selected ref and normalized source root
- Verified full revision
- Connection health without provider credentials
Relink or unlink
Project settings can relink a project after a fresh check of the replacement repository. Stale callbacks cannot overwrite a newer source selection. An organization connection can be unlinked only after every project using it has been relinked, and reconnecting creates a fresh authorization rather than restoring hidden state.
Provider scope
GitHub is the first supported source provider. The application boundary is provider-neutral so another provider can be added without changing project ownership, but no other provider is available today.