Preview deployments
Branch and pull request URLs for reviewing a change before it reaches production.
A preview deployment is an ordinary deployment that runs in an environment other than Production, so it never moves your production URL. Gigadrive Network builds one for every push to a branch that Production does not claim.
The URLs a preview gets
Two, and they answer different questions:
| URL | Points at |
|---|---|
<name>-git-<branch>.gigadrive.app | The latest deployment of that branch |
<name>-<id>.gigadrive.app | This one deployment, permanently |
Share the branch URL with a reviewer who wants to keep following the branch. Share the per-deployment URL in a bug report, where the point is that it will still show the same build tomorrow.
Both are listed on the deployment's Overview tab, with the one currently serving marked Current.
Pull requests and merge requests
With a repository linked and automatic deployments on, the push that opens a pull request has usually already produced a deployment. Opening the pull request links that deployment to it and reports back. When no deployment exists for the head commit yet, which happens if the branch was pushed before the application was linked, the pull request event builds it. GitLab merge requests work the same way, on their opened, reopened, and updated events.
Settings, Git controls whether a push deploys and what is written back to GitHub:
| Setting | Default | What it does |
|---|---|---|
| Automatic deployments | On | Deploy on pushes and pull requests. |
| Deployment Check | On | One GitHub Check that tracks the deployment's progress. |
| Legacy commit status | Off | A commit status instead of the Check, for older branch protection rules. |
| Deployment environment | On | Creates GitHub Deployment objects, which is what puts the preview URL in the pull request. |
| Pull request comments | On | Posts and updates one summary comment on the pull request. |
The Check and the legacy commit status are mutually exclusive; turning one on turns the other off. The summary comment is one comment per pull request shared by every application linked to that repository, so a monorepo with four applications gets one comment listing four deployments rather than four comments.
Whatever you enable, reporting to GitHub is best effort. A GitHub outage delays the comment, never the deployment. The settings are also snapshotted onto each deployment when it is created, so flipping a switch mid-build does not leave a Check stuck in progress.
A GitLab project has its own set of toggles on the same page, with no Check among them:
| Setting | What it does |
|---|---|
| Automatic deployments | Deploy branch pushes and merge request updates |
| Commit status | Publish deployment progress on the GitLab commit |
| GitLab environment | Publish production and preview deployments to GitLab Environments |
| Merge request summary | Maintain one sticky preview note on each merge request |
Connect a GitLab project covers the rest of that integration.
Pull requests from forks do not deploy
A pull request is built only when its head branch lives in the linked repository itself. A pull request opened from a fork is recorded, and no deployment is created for it. A GitLab merge request from a forked project is skipped for the same reason.
After a pull request closes
Closing or merging a pull request records the new state and stops there. The branch URL keeps serving the last deployment of that branch, and the deployments themselves stay where they are. Nothing is torn down.
What a preview is configured with
A preview build resolves environment variables the same way any other deployment does: organization values first, then application-wide values, then values scoped to the environment the branch resolved to. A variable set only on Production is not visible to a preview, which is the point of scoping it there.
Values marked sensitive can only be set on the Production and Preview environments, so a custom environment cannot hold a secret. Sensitive values covers that rule.
Storage buckets belong to an environment as well, so a preview reads and writes the Preview environment's buckets rather than production data. Environments lists everything that is scoped this way.