Connect a GitHub repository
Install the Gigadrive GitHub App, link a repository to an application, and control what a push deploys.
Linking a repository is what turns a push into a deployment. On GitHub that runs through a GitHub App you install on the account or organization that owns the code. For GitLab.com, see Connect a GitLab project instead.
Install the App and link a repository
Connect your GitHub account
On the Git page in application settings, or on the Import from Git tab of the new application dialog, choose Connect GitHub Account. This links your GitHub identity to your Gigadrive account so the console can list what you have access to. You can review it later under Connected accounts.
Install the GitHub App on a namespace
Choose Install GitHub App, or Add GitHub namespace from the account dropdown. GitHub asks which account or organization to install into, and whether the App may read all repositories or only selected ones. One Gigadrive organization can use several GitHub namespaces at once, and one namespace can serve several Gigadrive organizations: whoever can reach the installation on GitHub can link its repositories.
Link the repository to an application
Back in the console, pick the account in the dropdown, find the repository, and confirm. The repository and installation are stored on the application, and from then on a push to it can deploy. Several applications may point at the same repository; each one builds and deploys on its own.
What the App can do
The App is granted one permission set for the whole installation. Reading your code is what a build needs; every write is a report back to GitHub, and each of those has a per-application toggle.
| Access | What it is for |
|---|---|
| Read repository contents | Fetch the commit being deployed, and resolve a branch or a short SHA to it |
| Read repository metadata | List your repositories in the console picker |
Receive push and pull_request | Start a build when you push or open a pull request |
| Write checks | The Deployment Check that reports build progress on a commit |
| Write commit statuses | The legacy commit status, for older branch protection rules |
| Write deployments | GitHub Deployment objects, so the preview URL shows up on the pull request |
| Write pull request comments | The summary comment posted on a pull request and kept up to date |
The Git settings page carries a toggle for each report. Turning off Automatic deployments stops builds without unlinking anything, and Deployment Check and Legacy commit status are mutually exclusive: enabling the legacy status replaces the check.
Which accounts you can pick
A personal namespace appears only when the installation is on your own GitHub account. An organization namespace appears only when you are an active member of that GitHub organization. Being a collaborator on a single repository is not enough for either.
If a repository is missing from the list, the App is installed but was not granted access to it. Open the App's configuration on GitHub, add the repository, and refresh the list in the console.
What happens on a push
Only pushes to branches deploy. A tag, a branch deletion, and anything outside refs/heads/ are ignored.
The branch decides where the deployment goes. Production claims main and master on a new application, Preview takes everything else, and you can change the patterns per environment on the Environments settings page. See Projects and environments for how that resolution works.
Two rules keep a burst of pushes from piling up. A commit that already has a deployment that did not fail, for the same application, branch, and repository, is not built again. And once a newer commit on a branch is safely queued, builds still running for older commits on that branch are cancelled.
Pull requests are handled when they are opened, reopened, and updated with a new commit. A pull request from a fork is not deployed, because the installation has no token for the fork. Closing or merging a pull request records the state but leaves the deployment and its URL reachable.
Disconnecting
Disconnect, on the Git settings page, unlinks the repository from that application. Automatic deployments stop; existing deployments keep serving and are not touched.
Two things on the GitHub side unlink for you. Removing a repository from the App's access removes it from every application that pointed at it, and uninstalling the App unlinks every application in that namespace. Both are recorded in the audit log.