Connect a GitLab project

GitLab.com projects deploy on every push, the same way GitHub repositories do. The connection works differently: instead of an app you install per namespace, your organization authorizes Gigadrive once through GitLab OAuth, and every application in the organization links its project through that one connection.

Connect GitLab and link a project

1. Connect GitLab to the organization

   On the Git page in application settings, or on the Import from Git tab of the new application dialog, choose GitLab, then Connect GitLab. GitLab asks you to authorize Gigadrive, and you return to the console with the connection made.

   Only an organization owner or admin can do this. Everyone else sees "An organization admin must connect GitLab" and needs one of them to connect it first.

2. Pick the project

   The picker lists your GitLab projects grouped by top-level namespace. Choose one and confirm. Gigadrive stores the project on the application and adds a webhook to it, which is what turns a later push into a deployment.

3. Deploy

   From then on a push to the project deploys. An application links to one provider at a time: if it already has a GitHub repository, disconnect that first, and the console answers "Disconnect the GitHub repository before linking GitLab" until you do.

One connection per organization

An organization holds a single GitLab connection, and every application in it links through that one. This is the part that differs most from GitHub, where an installation is addressed by its own id and several organizations can link repositories from it. A GitLab connection belongs to exactly one organization, so a second organization that wants the same GitLab projects authorizes its own.

The connection carries the GitLab permissions of the admin who made it, and Gigadrive asks GitLab for the api scope. Only projects where that account has the Maintainer role or above are listed and linkable, because adding a webhook needs it. A project you can only push to does not appear.

What happens on a push

Only pushes to branches deploy. Anything outside refs/heads/ is ignored, and a commit that already has a deployment that did not fail, on the same application and branch, is not built again.

The branch decides where the deployment goes, exactly as it does for GitHub: Production claims main and master on a new application, Preview takes everything else, and the patterns are yours to change per environment. Projects and environments covers that resolution.

Merge requests are handled when they are opened, reopened, and updated with a new commit. A merge request from a fork is not deployed, because the build would need access the connection does not have.

What Gigadrive reports back

The Git settings page carries a toggle for each report, all on by default.

Turning off Automatic deployments stops builds without unlinking anything. GitLab environment is what puts the preview URL on the merge request, and it writes to GitLab's own Environments feature, which is a separate thing from the environments your application has on Gigadrive. There is no equivalent of GitHub's Deployment Check: on GitLab the commit status is the only per-commit report.

Disconnecting

Unlinking one application, from its Git settings page, removes that project's webhook and leaves the organization's connection and every other application alone.

Disconnect GitLab removes the connection for the whole organization: it deletes the webhook from every linked project, revokes the OAuth token at GitLab, and unlinks GitLab from every application in the organization. Existing deployments keep serving. Only an owner or admin can do it, and it is refused while a deployment is still building, so wait for in-flight builds to finish.

Both are recorded in the audit log.